[Mehdi2277]

I’ve heavily used both mypy/pyright.

The semantic differences are mainly in areas where type system is not specific enough on exact behavior expected. As an example if you have a function that has overloads how do you decide which overload to pick? Sometimes that can become ambiguous especially when type variables are involved or multiple overloads match. Cases like that are where you see most intentional differences and as a user of both type checkers I consider depending on specific behavior there to be like using c++ compiler’s undefined behavior.

The bigger area I see differences is feature development/bug fix velocity. Mypy is maintained well. Pyright is maintained magically and I’ve reported bugs that maintainer fixes the same day. Most bug reports to pyright get fixed in a week. Only a couple tend to stay open for a while. New type system features (peps) get implemented really fast in pyright and usually if you try to use very recent features you will need to wait a while for mypy to catch up. A good example is release time for paramspecs or typevartuple. Most of the time new type system peps are added in pyright while still in draft stage.

[Recursing]

An important difference is that pyright doesn't support plug-ins.

https://github.com/microsoft/pyright/issues/607

E.g. https://github.com/Shoobx/mypy-zope can't work with pyright

[samwillis]

After quickly skimming that issue thread I think the Pyright devs have a very compelling argument not to add a plug-in system. It would encourage none standard behaviour, when really the type system should be capable of describing all behaviour. I think it may be another plus for it.

[goodoldneon]

I appreciate that argument but some codebases are heavily reliant on “magic” libraries like SQLAlchemy. The SQLAlchemy mypy plugin helps a lot. Well, at least with SQLAlchemy 1.4; dunno if 2.0 needs the plugin

[zzzeek]

we've worked very heavily with the pyright developers directly on some aspects of SQLAlchemy 2.0, namely the new dataclasses feature : https://docs.sqlalchemy.org/en/20/orm/dataclasses.html#decla...

that said, the codebase primarily targets mypy for internal type checking; we tried targeting both tools simultaneously but there were great differences between both tools, which tended towards doubling our workload in getting everything to pass typing fully. In more than one case there were areas where the two tools would mutually disagree with each other, making "correct" typing impossible. This was some iterations back and mypy has had a lot of good releases since then (pyright has had many more, obviously).

when typing a large codebase, there are invariably lots of areas where you just need to "type: ignore" or otherwise do some non-ideal workarounds. it's in that area that trying to target more than one type checker at once gets to be really difficult.

[goodoldneon]

Sweet! I might have to work on upgrading us from 1.4 to 2.0

[solarkraft]

I ran into this issue recently. 2.0 will not need the plugin and work with any Python type checker! So much so that the plugin is already somewhat deprecated.

[fbdab103]

That is most welcome news. I use VSCode, and the amount of unparseable magic makes working with the library more annoying than I would like.

[solarkraft]

Yup. Lots of casting or # type: ignore for now.

Here's an official bit about the new types: https://docs.sqlalchemy.org/en/20/changelog/whatsnew_20.html...

[boxed]

Seems like dubious logic to me. For example the Django ORM is quite big. Just saying that the type system should handle it and giving up on Django is not a pragmatic choice.