5 ms·

To the obvious question: how does this differ from mypy? tldr; mostly about performance improvements but there's also semantic differences. The latter sounds l

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). https://github.com/microsoft/pyright/blob/main/docs/mypy-comparison.md https://github.com/microsoft/pyright/blob/main/docs/mypy-com....

Mehdi2277 4y ago
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 4y ago
  An important difference is that pyright doesn't support plug-ins. https://github.com/microsoft/pyright/issues/607 https://github.com/microsoft/pyright/issues/607 E.g. https://github.com/Shoobx/mypy-zope https://github.com/Shoobx/mypy-zope can't work with pyright
  - samwillis 4y ago
    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 4y ago
      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
      - solarkraft 4y ago
        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 4y ago
        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 4y ago
        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#new-typing-support-in-core-and-orm-stubs-extensions-no-longer-used https://docs.sqlalchemy.org/en/20/changelog/whatsnew_20.html...
      - zzzeek 4y ago
        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#declarative-dataclass-mapping 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.
bfung 4y ago
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.
- mananaysiempre 4y ago
  Pyright was designed by Microsoft to serve as the core of a proprietary[1], DRM-locked[2,3] Python language server, yes. [1] https://github.com/microsoft/pylance-release/issues/4 https://github.com/microsoft/pylance-release/issues/4 [2] https://github.com/microsoft/pylance-release/issues/746 https://github.com/microsoft/pylance-release/issues/746 [3] https://parsiya.net/blog/2021-12-20-rce-in-visual-studio-codes-remote-wsl-for-fun-and-negative-profit/#your-editor-has-drm https://parsiya.net/blog/2021-12-20-rce-in-visual-studio-cod...
  - satvikpendem 4y ago
    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.
    - mananaysiempre 4y ago
      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.) [1] https://github.com/microsoft/python-language-server/issues/2096 https://github.com/microsoft/python-language-server/issues/2...
ossopite 4y ago
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.
- davepeck 4y ago
  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.
- dataflow 4y ago
  An example of where mypy chokes: def foo(data: list[str]): r = [] # error: Need type annotation for key in data: r.append(key if len(r) > 0 else '') return r
deleted 4y ago
[deleted]

Mehdi2277 4y ago

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 4y ago
An important difference is that pyright doesn't support plug-ins. https://github.com/microsoft/pyright/issues/607 https://github.com/microsoft/pyright/issues/607 E.g. https://github.com/Shoobx/mypy-zope https://github.com/Shoobx/mypy-zope can't work with pyright
- samwillis 4y ago
  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 4y ago
    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
    - solarkraft 4y ago
      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 4y ago
        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 4y ago
        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#new-typing-support-in-core-and-orm-stubs-extensions-no-longer-used https://docs.sqlalchemy.org/en/20/changelog/whatsnew_20.html...
    - zzzeek 4y ago
      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#declarative-dataclass-mapping 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.

bfung 4y ago

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.

mananaysiempre 4y ago
Pyright was designed by Microsoft to serve as the core of a proprietary[1], DRM-locked[2,3] Python language server, yes. [1] https://github.com/microsoft/pylance-release/issues/4 https://github.com/microsoft/pylance-release/issues/4 [2] https://github.com/microsoft/pylance-release/issues/746 https://github.com/microsoft/pylance-release/issues/746 [3] https://parsiya.net/blog/2021-12-20-rce-in-visual-studio-codes-remote-wsl-for-fun-and-negative-profit/#your-editor-has-drm https://parsiya.net/blog/2021-12-20-rce-in-visual-studio-cod...
- satvikpendem 4y ago
  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.
  - mananaysiempre 4y ago
    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.) [1] https://github.com/microsoft/python-language-server/issues/2096 https://github.com/microsoft/python-language-server/issues/2...

ossopite 4y ago

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.

davepeck 4y ago
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.
dataflow 4y ago
An example of where mypy chokes: def foo(data: list[str]): r = [] # error: Need type annotation for key in data: r.append(key if len(r) > 0 else '') return r

deleted 4y ago

[deleted]