[zem]

sorry, I didn't mean to sound dismissive of the problem, I just believe it is a problem that having more actively developed type checkers will make better rather than worse. with my type checker developer hat on, the end goal is not to have a single type checker and have the implementation be the spec, it's to have an evolving set of standards that (ideally) can express the patterns people want from python, and then have the type checkers work with those standards.

pep695 is a good example of how the spec is still evolving to try and make the explicit type system work better for python developers. dataclass transforms are perhaps an even better example - that's a pattern that is very specific to python and based on real world, non-typing-related ways in which people use the language, and which they wanted the annotation system to cover, and there was a collaborative effort to develop a way to do it.

also note that there are escape hatches like error suppression (e.g. if pyright likes some code but mypy wrongly thinks it's a type error, you can add a comment so that mypy ignores that one error while continuing to have pyright check it) and typing.cast (which is a directive all the type checkers honour, to say "trust me, this variable has this particular type whether or not you can verify it statically").

another thing to consider is that having type checking work interactively in the IDE is something a lot of people want, and pyright was developed specifically to support that feature. mypy, pytype, and pyre were all architected as batch type checkers, i.e. they need to run on a complete program as a standalone process, and it would have been anywhere from difficult to impossible to get them to support the type of incremental checking an IDE requires.