5 ms·

Very excited for this, looks like it's built on top of pretty solid technical foundations (iirc, it uses salsa from rust for incremental type checking). I've fo

Very excited for this, looks like it's built on top of pretty solid technical foundations (iirc, it uses salsa from rust for incremental type checking). I've found mypy pretty terrible. Pyright is okay (but requires node). Ruff truly can become one tool to rule them all.

dcreager 2y ago
> it uses salsa from rust for incremental type checking This is true! We're also contributing salsa features upstream where we can, e.g. https://github.com/salsa-rs/salsa/pull/603 https://github.com/salsa-rs/salsa/pull/603
IshKebab 2y ago
I agree, Mypy is awful. Pyright is very good but also quite slow, and its Node requirement is awkward in some cases (e.g. pre-commit). A fast Rust based type checker would be amazing!
- Noumenon72 2y ago
  I'd appreciate knowing what's wrong with MyPy that this project will fix. Check time? Bad rules? Lack of features?
  - tcdent 2y ago
    yeah, 'awful' is just the OP being dramatic, though I am looking forward to Astral's contribution
    - theLiminator 2y ago
      I think that https://github.com/microsoft/pyright/blob/main/docs/mypy-comparison.md https://github.com/microsoft/pyright/blob/main/docs/mypy-com... actually covers the majority of my gripes with mypy, the main issues I encounter with mypy are due to its lack of precision. It produces a lot of false positives for code that is well-typed that pyright can handle. Also the lack of type inference and lack of type checking for unannotated code (by default) is kinda painful. Mypy in general makes certain patterns which are pythonic not typecheck whilst pyright is a lot less painful in that regard. I've personally found that dealing with mypy has been more noisy and painful than using pyright and leads to a lot of users/other devs just ignoring typing altogether. I think that type checking has to closely match the semantics of the language and if there's a gap, it will often push users to do the easy thing, which is just ignoring checks.
  - arthur-st 2y ago
    MyPy's rules are reference-grade, being as close to an official spec as we get until the Typing Council is done establishing their moat. To understand shortcomings of MyPy, I strongly suggest reading pyright's documentation for how they compare: https://github.com/microsoft/pyright/blob/main/docs/mypy-comparison.md https://github.com/microsoft/pyright/blob/main/docs/mypy-com... Quoting the pertinent part: > Pyright was designed with performance in mind. It is not unusual for pyright to be 3x to 5x faster than mypy when type checking large code bases. Some of its design decisions were motivated by this goal. > Pyright was also designed to be used as the foundation for a Python language server. Language servers provide interactive programming features such as completion suggestions, function signature help, type information on hover, semantic-aware search, semantic-aware renaming, semantic token coloring, refactoring tools, etc. For a good user experience, these features require highly responsive type evaluation performance during interactive code modification. They also require type evaluation to work on code that is incomplete and contains syntax errors. > To achieve these design goals, pyright is implemented as a “lazy” or “just-in-time” type evaluator. Rather than analyzing all code in a module from top to bottom, it is able to evaluate the type of an arbitrary identifier anywhere within a module. If the type of that identifier depends on the types of other expressions or symbols, pyright recursively evaluates those in turn until it has enough information to determine the type of the target identifier. By comparison, mypy uses a more traditional multi-pass architecture where semantic analysis is performed multiple times on a module from the top to the bottom until all types converge. > Pyright implements its own parser, which recovers gracefully from syntax errors and continues parsing the remainder of the source file. By comparison, mypy uses the parser built in to the Python interpreter, and it does not support recovery after a syntax error. This also means that when you run mypy on an older version of Python, it cannot support newer language features that require grammar changes. Astral's type checker seems to an exercise in speeding up Pyright's approach to designing a type checker, and removing the Node dependency from it.
    - zelphirkalt 2y ago
      I haven't had any issues from MyPy regarding speed. So performance issues did not exist whenever I used MyPy. Also not sure why I need incremental anything. I save a file and then I want it to be checked. If I am not implementing a LS, then how is it of any importance, whether the type checker was designed with typing a LS? How does that benefit me in my normal projects? If there are no semantic improvements, that allow more type inference than MyPy allows, I don't see much going for Pyright. Sounds like a "ours is blazingly faster than the other" kind of sales pitch.
  - IshKebab 2y ago
    I found performance not that different to Pyright. The major difference is quality and correctness. Mypy is full of weird bugs and insane typing holes. I found cases where it would even treat `foo: SomeType` and `foo # type: SomeType` differently! I tried to fix that one but looking into the code lowered my impression of it even further. It's a complete mess. It's not at all a surprise that it gets so many things wrong. Overall Mypy is like kind of like a type checker written by people who've only ever seen linters before. It checks some types but it's kind of wooly and heuristic and optional. Pyright is a type checker written by someone who knows what they are doing. It is mostly sound, doesn't just say "eh we won't check that" half the time, and has barely any bugs. Seriously check the closed/open issues on Github - there's a touch of "I disagree so I'm closing that" but only a touch. It mostly has so few open issues because the main author is a machine. The only real problems with it are performance (it's ok but definitely could be better), and the slightly annoying dependence on Node.
    - akoboldfrying 2y ago
      I upvoted as your comment sounds reasonable, but in a sibling comment I see: >By comparison [to pyright], mypy uses a more traditional multi-pass architecture where semantic analysis is performed multiple times on a module from the top to the bottom until all types converge That makes it sound like mypy does in fact do The Right Thing (albeit the slower, less-suitable-for-LSP thing), rather than a messy pile of heuristic/optional hacks.
    - SOLAR_FIELDS 2y ago
      Not really knowing fully about how type checkers work, one thing I struggled with a fair amount working with Mypy is how the stubs made available from various libraries were both all over the place in quality and not straightforward as a beginner to get working. Is this approach of using stubs a requirement for basically any static type checker that Python uses, or is this a specific way that Mypy chose to implement this concept?
      - Yoric 2y ago
        Yes, I think that is actually the greatest weakness of mypy: the ecosystem is hostile to static typing.
  - harrall 2y ago
    This is a good summary: https://github.com/microsoft/pyright/blob/main/docs/mypy-comparison.md https://github.com/microsoft/pyright/blob/main/docs/mypy-com... But without that, I always felt like I was actively fighting mypy. It seemed like it was written for a totally different language than Python. Compared to another more modern type system like TypeScript, sometimes you don't explicitly type something and yet TypeScript usually does exactly what you expect.
  - pushfoo 2y ago
    Lacking named tuple support is a deal-breaker for some projects. This is directly from their GitHub issues comments[1]: > Duplicate of #5613, still low priority, better use dataclasses, as suggested above. 1. https://github.com/python/mypy/issues/5944#issuecomment-441285456 https://github.com/python/mypy/issues/5944#issuecomment-4412...
  - maxloh 2y ago
    Pyright infers return types for me correctly in most cases, while mypy couldn't even property infer the return type of void functions (you have to specify `-> None` explicitly).
- zeotroph 2y ago
  There is third, pytype (by google), which I found pretty good but it rarely gets mentioned. However, like the others it is slow, so I hope this one is fast and supports all the pytype features (especially being able to type-check un-annotated code). https://github.com/google/pytype?tab=readme-ov-file#pytype--- https://github.com/google/pytype?tab=readme-ov-file#pytype--...
  - arthur-st 2y ago
    To round out the big 4, there's also Pyre from Meta. I haven't used it myself, as when I last checked it had a low number of PEPs covered, but I've heard some good words for it.
- vintagedave 2y ago
  What about beartype[1]? It's blazingly fast -- plus the docs are amazing in multiple ways. [1] https://github.com/beartype/beartype https://github.com/beartype/beartype
  - olejorgenb 2y ago
    Looks like a runtime checker to me: https://beartype.readthedocs.io/en/latest/faq/#does-beartype-actually-do-anything https://beartype.readthedocs.io/en/latest/faq/#does-beartype...
- pjc50 2y ago
  When I tried pyright I immediately bailed on the requirement for Node, which seems absolutely bananas. Mypy is at least written in its own dogfood of python.
insane_dreamer 2y ago
I've found pyright to be limited in its ability to infer types, especially compared to Pycharm, which can resolve class inherence across multiple modules quite well. I noticed this when trying to use Zed instead of Pycharm.
- arthur-st 2y ago
  Check if your configuration allows pyright to use other files in the workspace.
- olejorgenb 2y ago
  If you actually type your code [1], pyright is miles ahead pycharm in every case I've seen. For partially/incorrectly typed code pycharm is often better in practice because it relies on heuristics. (tbf. Some libraries lack or have bad stubs, which can be annoying using pyright (eg. Pandas)). [1] You don't have to typehint everything for this to work. Pyright infers return types just fine for instance
sgarland 2y ago
I've avoided Pyright explicitly for that reason. I have a severe dislike of Node, and don't want it installed on my computer for any reason. I'm aware that this is a self-limiting position. Anyway, agreed that this is very exciting news. Poetry was great, and then I found uv. It's... wow. It's really good.
- pinoy420 2y ago
  Node is fine. This is very much old man shouts at cloud. Pyright is really quick. Node is fast enough for a majority of uses.
  - sgarland 2y ago
    I don’t dislike it because it’s not fast enough; I dislike it because I associate with the rise of tech influencers, who are at best charlatans, and who at worst have helped to usher in an Eternal September far worse than Web2.0 could ever have dreamt of doing.
    - ripped_britches 2y ago
      Node did this? A fully optional JS runtime that isn’t used in browsers? Who hurt you?
      - sgarland 2y ago
        > Who hurt you? Web devs; I thought that was implied.
  - rednafi 2y ago
    Not old and not yelling at anything. I don’t have any qualms about installing tools that depend on Node, as I use VSCode and therefore Pyright all the time. That said, Node is awful as a backend language, and speed has nothing to do with it. I will write Go, Python, Rust, or anything else because of how those languages have been designed. JS doesn’t belong in my backend—YMMV.
  - 2y ago
craigds 2y ago
Mypy is currently the only one that can handle Django projects (because it has a plugin system and there's a plugin that can import your django code to infer types) Unfortunately that massively limits its performance too since loading a large django codebase is pretty slow.

dcreager 2y ago

> it uses salsa from rust for incremental type checking This is true! We're also contributing salsa features upstream where we can, e.g. https://github.com/salsa-rs/salsa/pull/603 https://github.com/salsa-rs/salsa/pull/603

IshKebab 2y ago

I agree, Mypy is awful. Pyright is very good but also quite slow, and its Node requirement is awkward in some cases (e.g. pre-commit). A fast Rust based type checker would be amazing!

Noumenon72 2y ago
I'd appreciate knowing what's wrong with MyPy that this project will fix. Check time? Bad rules? Lack of features?
- tcdent 2y ago
  yeah, 'awful' is just the OP being dramatic, though I am looking forward to Astral's contribution
  - theLiminator 2y ago
    I think that https://github.com/microsoft/pyright/blob/main/docs/mypy-comparison.md https://github.com/microsoft/pyright/blob/main/docs/mypy-com... actually covers the majority of my gripes with mypy, the main issues I encounter with mypy are due to its lack of precision. It produces a lot of false positives for code that is well-typed that pyright can handle. Also the lack of type inference and lack of type checking for unannotated code (by default) is kinda painful. Mypy in general makes certain patterns which are pythonic not typecheck whilst pyright is a lot less painful in that regard. I've personally found that dealing with mypy has been more noisy and painful than using pyright and leads to a lot of users/other devs just ignoring typing altogether. I think that type checking has to closely match the semantics of the language and if there's a gap, it will often push users to do the easy thing, which is just ignoring checks.
- arthur-st 2y ago
  MyPy's rules are reference-grade, being as close to an official spec as we get until the Typing Council is done establishing their moat. To understand shortcomings of MyPy, I strongly suggest reading pyright's documentation for how they compare: https://github.com/microsoft/pyright/blob/main/docs/mypy-comparison.md https://github.com/microsoft/pyright/blob/main/docs/mypy-com... Quoting the pertinent part: > Pyright was designed with performance in mind. It is not unusual for pyright to be 3x to 5x faster than mypy when type checking large code bases. Some of its design decisions were motivated by this goal. > Pyright was also designed to be used as the foundation for a Python language server. Language servers provide interactive programming features such as completion suggestions, function signature help, type information on hover, semantic-aware search, semantic-aware renaming, semantic token coloring, refactoring tools, etc. For a good user experience, these features require highly responsive type evaluation performance during interactive code modification. They also require type evaluation to work on code that is incomplete and contains syntax errors. > To achieve these design goals, pyright is implemented as a “lazy” or “just-in-time” type evaluator. Rather than analyzing all code in a module from top to bottom, it is able to evaluate the type of an arbitrary identifier anywhere within a module. If the type of that identifier depends on the types of other expressions or symbols, pyright recursively evaluates those in turn until it has enough information to determine the type of the target identifier. By comparison, mypy uses a more traditional multi-pass architecture where semantic analysis is performed multiple times on a module from the top to the bottom until all types converge. > Pyright implements its own parser, which recovers gracefully from syntax errors and continues parsing the remainder of the source file. By comparison, mypy uses the parser built in to the Python interpreter, and it does not support recovery after a syntax error. This also means that when you run mypy on an older version of Python, it cannot support newer language features that require grammar changes. Astral's type checker seems to an exercise in speeding up Pyright's approach to designing a type checker, and removing the Node dependency from it.
  - zelphirkalt 2y ago
    I haven't had any issues from MyPy regarding speed. So performance issues did not exist whenever I used MyPy. Also not sure why I need incremental anything. I save a file and then I want it to be checked. If I am not implementing a LS, then how is it of any importance, whether the type checker was designed with typing a LS? How does that benefit me in my normal projects? If there are no semantic improvements, that allow more type inference than MyPy allows, I don't see much going for Pyright. Sounds like a "ours is blazingly faster than the other" kind of sales pitch.
- IshKebab 2y ago
  I found performance not that different to Pyright. The major difference is quality and correctness. Mypy is full of weird bugs and insane typing holes. I found cases where it would even treat `foo: SomeType` and `foo # type: SomeType` differently! I tried to fix that one but looking into the code lowered my impression of it even further. It's a complete mess. It's not at all a surprise that it gets so many things wrong. Overall Mypy is like kind of like a type checker written by people who've only ever seen linters before. It checks some types but it's kind of wooly and heuristic and optional. Pyright is a type checker written by someone who knows what they are doing. It is mostly sound, doesn't just say "eh we won't check that" half the time, and has barely any bugs. Seriously check the closed/open issues on Github - there's a touch of "I disagree so I'm closing that" but only a touch. It mostly has so few open issues because the main author is a machine. The only real problems with it are performance (it's ok but definitely could be better), and the slightly annoying dependence on Node.
  - akoboldfrying 2y ago
    I upvoted as your comment sounds reasonable, but in a sibling comment I see: >By comparison [to pyright], mypy uses a more traditional multi-pass architecture where semantic analysis is performed multiple times on a module from the top to the bottom until all types converge That makes it sound like mypy does in fact do The Right Thing (albeit the slower, less-suitable-for-LSP thing), rather than a messy pile of heuristic/optional hacks.
  - SOLAR_FIELDS 2y ago
    Not really knowing fully about how type checkers work, one thing I struggled with a fair amount working with Mypy is how the stubs made available from various libraries were both all over the place in quality and not straightforward as a beginner to get working. Is this approach of using stubs a requirement for basically any static type checker that Python uses, or is this a specific way that Mypy chose to implement this concept?
    - Yoric 2y ago
      Yes, I think that is actually the greatest weakness of mypy: the ecosystem is hostile to static typing.
- harrall 2y ago
  This is a good summary: https://github.com/microsoft/pyright/blob/main/docs/mypy-comparison.md https://github.com/microsoft/pyright/blob/main/docs/mypy-com... But without that, I always felt like I was actively fighting mypy. It seemed like it was written for a totally different language than Python. Compared to another more modern type system like TypeScript, sometimes you don't explicitly type something and yet TypeScript usually does exactly what you expect.
- pushfoo 2y ago
  Lacking named tuple support is a deal-breaker for some projects. This is directly from their GitHub issues comments[1]: > Duplicate of #5613, still low priority, better use dataclasses, as suggested above. 1. https://github.com/python/mypy/issues/5944#issuecomment-441285456 https://github.com/python/mypy/issues/5944#issuecomment-4412...
- maxloh 2y ago
  Pyright infers return types for me correctly in most cases, while mypy couldn't even property infer the return type of void functions (you have to specify `-> None` explicitly).
zeotroph 2y ago
There is third, pytype (by google), which I found pretty good but it rarely gets mentioned. However, like the others it is slow, so I hope this one is fast and supports all the pytype features (especially being able to type-check un-annotated code). https://github.com/google/pytype?tab=readme-ov-file#pytype--- https://github.com/google/pytype?tab=readme-ov-file#pytype--...
- arthur-st 2y ago
  To round out the big 4, there's also Pyre from Meta. I haven't used it myself, as when I last checked it had a low number of PEPs covered, but I've heard some good words for it.
vintagedave 2y ago
What about beartype[1]? It's blazingly fast -- plus the docs are amazing in multiple ways. [1] https://github.com/beartype/beartype https://github.com/beartype/beartype
- olejorgenb 2y ago
  Looks like a runtime checker to me: https://beartype.readthedocs.io/en/latest/faq/#does-beartype-actually-do-anything https://beartype.readthedocs.io/en/latest/faq/#does-beartype...
pjc50 2y ago
When I tried pyright I immediately bailed on the requirement for Node, which seems absolutely bananas. Mypy is at least written in its own dogfood of python.

insane_dreamer 2y ago

I've found pyright to be limited in its ability to infer types, especially compared to Pycharm, which can resolve class inherence across multiple modules quite well. I noticed this when trying to use Zed instead of Pycharm.

arthur-st 2y ago
Check if your configuration allows pyright to use other files in the workspace.
olejorgenb 2y ago
If you actually type your code [1], pyright is miles ahead pycharm in every case I've seen. For partially/incorrectly typed code pycharm is often better in practice because it relies on heuristics. (tbf. Some libraries lack or have bad stubs, which can be annoying using pyright (eg. Pandas)). [1] You don't have to typehint everything for this to work. Pyright infers return types just fine for instance

sgarland 2y ago

I've avoided Pyright explicitly for that reason. I have a severe dislike of Node, and don't want it installed on my computer for any reason. I'm aware that this is a self-limiting position. Anyway, agreed that this is very exciting news. Poetry was great, and then I found uv. It's... wow. It's really good.

pinoy420 2y ago
Node is fine. This is very much old man shouts at cloud. Pyright is really quick. Node is fast enough for a majority of uses.
- sgarland 2y ago
  I don’t dislike it because it’s not fast enough; I dislike it because I associate with the rise of tech influencers, who are at best charlatans, and who at worst have helped to usher in an Eternal September far worse than Web2.0 could ever have dreamt of doing.
  - ripped_britches 2y ago
    Node did this? A fully optional JS runtime that isn’t used in browsers? Who hurt you?
    - sgarland 2y ago
      > Who hurt you? Web devs; I thought that was implied.
- rednafi 2y ago
  Not old and not yelling at anything. I don’t have any qualms about installing tools that depend on Node, as I use VSCode and therefore Pyright all the time. That said, Node is awful as a backend language, and speed has nothing to do with it. I will write Go, Python, Rust, or anything else because of how those languages have been designed. JS doesn’t belong in my backend—YMMV.
- 2y ago

craigds 2y ago

Mypy is currently the only one that can handle Django projects (because it has a plugin system and there's a plugin that can import your django code to infer types) Unfortunately that massively limits its performance too since loading a large django codebase is pretty slow.