tldr; mostly about performance improvements but there's also semantic differences. The latter sounds like it means a split between the community who decides to do mypy vs pyright. But maybe pyright only differs with mypy in terms of things that are considered bugs in mypy, and things that are optional in mypy (via flags).
https://github.com/microsoft/pyright/blob/main/docs/mypy-com....
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.
https://github.com/microsoft/pyright/issues/607
E.g. https://github.com/Shoobx/mypy-zope can't work with pyright
Here's an official bit about the new types: https://docs.sqlalchemy.org/en/20/changelog/whatsnew_20.html...
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.
You also have a lot more control with pyright over where unknown types are permitted or what other checks should be performed. Also, it can scan library source code to infer types which I don't think mypy supports.
The lack of plug-in support might feel like a hang-up, for instance if you’re using Django. FWIW, I like the “no plug-in” philosophy. I’ve discovered that explicitly adding annotations that a MyPy plug-in would have surmised feels cleaner. (Example: an annotation for a reverse collection on a Model referenced by a foreign key.) Even better: I don’t need to suffer the (in my experience) frequent bugs of the plugins themselves.
def foo(data: list[str]):
r = [] # error: Need type annotation
for key in data:
r.append(key if len(r) > 0 else '')
return rThis means being able to incrementally type check incomplete code blocks and to also infer & suggest types, where mypy is too slow and/or just doesn’t support those features.
[1] https://github.com/microsoft/pylance-release/issues/4
[2] https://github.com/microsoft/pylance-release/issues/746
[3] https://parsiya.net/blog/2021-12-20-rce-in-visual-studio-cod...
On the other hand, when Microsoft creates an interoperability standard to solve the proliferation of wheel-inventing in IDEs, actively promotes it as such, creates and supports an open-source implementation of it for Python as part of said promotion, then abandons[1] said implementation in favour of a proprietary one that deliberately speaks the interoperability protocol in a slightly non-interoperable way, then yes, I do feel like I’ve been conned, and maybe I should stop treating Microsoft’s open-source efforts seriously even if they’re good software at the present moment. (Whether my level of cynicism regarding Microsoft should have been high enough that I wouldn’t have been surprised, I’m not sure.)
[1] https://github.com/microsoft/python-language-server/issues/2...
Authors of other language servers deliberately chose to put up with Microsoft’s legacy-induced craziness in the protocol (positions in UTF-8-encoded strings specified as UTF-16 code unit counts, etc.) due to Microsoft’s promise of an interoperable ecosystem; then Microsoft reneged on that.
I’d have much less of a problem, for example, if I could use a proprietary Pylance with VS Codium or Neovim or whatever else I want; I’d have almost no problem if Microsoft also hadn’t published then abandoned an open-source Python language server first. But I can’t, and they did.
I just had a quick check and can't obviously see if that has been fixed/worked around in pylsp-mypy, on the off-chance that you might know :)