|
|
|
|
|
by staticassertion
1863 days ago
|
|
> Not that much as they all follow pep 484 + a few other peps. The number of type features unique to each one are generally bugs/recent peps they haven't implemented. 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.