To the obvious question: how does this differ from mypy?
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).
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.
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.
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
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.
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.
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.
The most important difference in my experience has been that pyright is a lot more rigorous and correct than mypy. I found that it was easy to confuse mypy, leaving large amounts of code unexpectedly not type checked. Put simply, I trust pyright and I do not trust mypy.
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.
My experience is much the same: pyright is fast, reliable, and (when it complains) correct. MyPy is… not always those things. The teams I know that use Python generally have all moved to pyright if they started with MyPy.
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.
A bit more specifically, looks like pyright was designed to serve as a language server for VS Code.
This 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.
You don't have to use Pylance though, just use Pyright itself. While it's a shame that Pylance isn't open source, I won't fault anyone for not doing so, that's their choice, just as I don't open source all of my code either.
I do fault them, a bit, philosophically, but that’s not even the core of my complaint here. I may not like Microsoft releasing proprietary software, but I hardly feel surprised or cheated when they do.
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.)
Pylance is used in a number of Microsoft products, quite a few of which are not open source, whereas the previous language server was only used in the VS Code and VS Python extensions, which are open source. There's your license difference explanation. As to why the old language server was retired, it had a different architecture which involved reindexing all the code all the time, and the team couldn't make it performant enough; pyright lazily evaluates just what is needed at the point it is needed.
Well, others are free to make their own language servers if they don't like the current implementations, just as we do with other proprietary software, ie GIMP vs Photoshop.
Again, “Microsoft creates proprietary software” (which is what your comment is responding to) is no news; “Microsoft starts interoperable ecosystem, gets everyone on board, then deliberately goes against the ecosystem’s interests” (which is incidentally accomplished by creating proprietary software) is my problem.
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 don't see a problem where you do, it seems. Anyone is free to make or not make whatever they want, that they made the ecosystem is enough for me, I've already derived enough benefit from it through interoperability with Neovim as well as VSCode, they simply don't have to make anything else beyond that; even if they initially started and stopped working on a Python language server, that is their prerogative. The ecosystem is no less interoperable just because they made a proprietary language server instead.
The last time I actively looked into it (granted, some months ago), it was somewhat hindered by https://github.com/python/mypy/issues/9309 causing it to re-evaluate sources quite a lot during editing even with mypyd.
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 :)
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....