In C, you ultimately care about what the compiler says. And this has also led to dialect-specific C code that works fine in one compiler but doesn't compile or runs incorrectly in another compiler.
If you are using the most recent pep features possible than yeah you might have an issue. That's similar to clang/gcc both taking time to implement new c++ standards and not being compatible there. If you only use pep 484 which covers most basics well then you should be good for any checker.
This is totally untrue? Pyre adds completely new notions like taint analysis, pytype adds a totally different inference system - the type systems are not compatible and it has nothing to do with implementation of PEPs.
The difference with C is that all of the other linters and analyzers are on top of the base type system, they don't replace it. In the case of Python the only standard part is where the annotations go and how they get resolved at runtime, it's otherwise completely up to the type system implementation to determine what's what, and all 3 of them do so in very different ways.
This is like if clang/gcc had totally different behaviors for `auto` in C++, but really it's not even comparable.
My base statement of 4 main type checkers are pep 484 compliant and that's main type checking most people refer to for python. If you get a type error that's inconsistent with that pep that's a bug. If you use a feature outside of any pep like plugins, taint analysis, pyright stub generation, then yes that is unspecified and can vary. Most engineers I work with python type checking stops mostly at basic type system and I'll sometimes point them to newer peps for better type definitions. My actual experience is most places don't consistently do any type checking at all although people tend to be open to it if you're fine guiding them/setting it up.
$ python -c 'import this' | sed -n 15p
There should be one-- and preferably only one --obvious way to do it.