Have you by any chance used Pyright? If not, I can highly recommend it. The VS Code extension makes writing Python almost as if it's a statically typed language (+ there is a CLI if you want to check types in CI). The docs are claiming that it's 3-5x faster than mypy - I haven't run performance benchmarks myself, all I can say is that for all my code bases it is very fast after the first cold start.
Comparison to mypy:
https://github.com/microsoft/pyright/blob/main/docs/mypy-com...
In Oxlint – JavaScript linter written in Rustmicrosoft
pyright
Python2019–2025
microsoft / pyright
pyright
Static Type Checker for Python
62Distinct people
68Mentions
0Explicit recommenders
15.7KGitHub stars
What to know before exploring
What it is
Static Type Checker for Python
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- google/pytype · linked in 6 of the same discussions
- python/mypy · linked in 5 of the same discussions
- meta/pyre-check · linked in 3 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 3:38:16 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year68 dated mentions
Observed mentions: 2019-03-24 01:55:38 UTC to 2025-12-22 22:51:45 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 15 | 0 | 15 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 14 | 1 | 13 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 16 | 2 | 14 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 11 | 0 | 11 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Static Type Checker for Python
Pyright is a full-featured, standards-based static type checker for Python. It is designed for high performance and can be used with large Python source bases.
Pyright includes both a command-line tool and an extension for Visual Studio Code.
Pyright Playground
Try Pyright in your browser using the Pyright Playground.
Documentation
Refer to the documentation for installation, configuration, and usage details.
Performance
The weekly type checker benchmark compares Pyright with other Python type checkers.
The Pyright release history tracks per-package execution time and peak memory across releases.
Environment variables
If Pyright fails to create a temporary directory (for example in remote/server environments where the OS temp directory doesn't exist or isn't writable), you can override the temp directory root:
PYRIGHT_TMPDIR: Absolute path to a directory that Pyright can use for temporary files/directories. Pyright will create it if needed.
Pyright otherwise relies on the platform temp directory (for example TMPDIR, TMP, TEMP, or the OS default).
Community
Do you have questions about Pyright or Python type annotations in general? Post your questions in the discussion section.
If you would like to report a bug or request an enhancement, file a new issue in either the pyright or pylance-release issue tracker. In general, core type checking functionality is associated with Pyright while language service functionality is associated with Pylance, but the same contributors monitor both repos. For best results, provide the information requested in the issue template.
Contributing
This project welcomes contributions and suggestions. For feature and complex bug fix contributions, it is recommended that you first discuss the proposed change with Pyright’s maintainers before submitting the pull request. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.
When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.
Read the full README on GitHubWhat Hacker News says
16 sourcesHave you checked out Pyright[1]? It's not one tool to rule then all, but it is nice and fast.
[1]https://github.com/microsoft/pyright
In Oxlint – JavaScript linter written in RustDo you know about Pyright? It is a Python type checker implemented in, and apparently influenced by, TypeScript. It is from Microsoft, so the influence is not that surprising.
There was a recent HN submission about it: https://news.ycombinator.com/item?id=34222407.
I use Pyright as my primary type checker and mypy as a secondary. (For example, Pyright won't run in Termux on my phone. I could likely fix this, but mypy just installs with pipx.) There is a document comparing Pyright and mypy in the Pyright repository: https://github.com/microsoft/pyright/blob/b09f35889a9cc9b262....
In Mypy 1.6Not exactly what you are looking for but maybe useful to others.
https://github.com/microsoft/pyright/blob/main/docs/mypy-com...
In Mypy 1.6Is anyone still using mypy, and if so why? I have replaced it by pyright [0] for a while now, and not looking back. It’s been a faster, more powerful replacement with (in my case), zero downside.
[0]: https://github.com/microsoft/pyright
In Mypy 1.6You can use pyright instead[0]. It is the FOSS version of pyright, but having some features missing.
[0]: https://github.com/microsoft/pyright
In VSCodium – Open-source binaries of VSCodeFunction annotations were added as part of Python 3.0, with PEP 3107, proposed in 2006 [0]. The first public mypy commit was in 2012 [1], and originally it was using C++-style syntax (`list<Token> lex(str s):`). The `typing` module and the official use of function annotation for type hints came in 2014 with PEP 484 [2], inspired by mypy. The first pyright commit was in 2019 (with a lot of code in the third commit [3], possibly moved from the VSCode extension).
[0] https://peps.python.org/pep-3107/
[1] https://github.com/python/mypy/commit/6f0826a9c169c4f05bb893...
[2] https://peps.python.org/pep-0484/
[3] https://github.com/microsoft/pyright/commit/1d91744b1f268fd0...
In The different uses of Python type hintsAsk HN: Is there a good PyCharm setup for Pyright?
Our Python team has been going down the road of strict static type checking using Pyright. To me, it looks like a better option than MyPy for us given the differences[0].
However, we are a mixed IDE shop and some of our developers really like PyCharm. I've been searching around for a nice plugin or something for them to use Pyright inside of PyCharm. But that doesn't seem to exist. Has anyone successfully used Pyright inside of PyCharm? It would be nice if there was more immediate feedback than waiting for pre-commit to catch your errors.
[0]: https://github.com/microsoft/pyright/blob/main/docs/mypy-comparison.md
5 points · Open discussionI've had lots of success using pyright [1] for Python projects, it has sensible defaults and can be configured with a pyproject.toml file so everyone's using the same settings. I use the Pylance VSCode extension to catch errors earlier, but I also put it in pre-commit and as a CI check, so all contributors are committing the same quality of typed code.
With more complex types, I've found it isn't necessary to do anything more complex than specifying the element type of a list or dict most of the time. I have typehinted lambda function arguments before, but just using the plain Callable typehint is usually enough. When I forget if I need to use an Iterator or an Iterable (which is every time), then I just try one and run the type checker and change it to the other if i guessed incorrectly.
Type checking Python can become complex if you exp
Read the rest
ect to be able to express everything in the typehints, but Python's type system isn't powerful enough for that. I feel its strength is that it lets you add as much detail to the types as is convenient.
[1] https://github.com/microsoft/pyright
The only one that's stuck with me is https://github.com/microsoft/pyright, mainly because I thought it was strange that Microsoft would publish something such a lackluster README. It's not the worst ever, but it lacks a clear sales pitch and a concise explanation of why you'd use it instead of mypy. If you go in without that added context, it's kind of mystifying why it even exists or why you'd use it compared with the alternatives.
In 10x C++ EditorFor Neovim users that use LSP + completion + snippets, it is slightly unfortunate that the Pyright team does not plan to support snippets on Pyright (but open to supporting it on Pylance, which is not OSS).
https://github.com/microsoft/pyright/issues/924
In Pyright: Static Type Checker for PythonThis issue has some pointers:
https://github.com/microsoft/pyright/discussions/3222
In Pyright: Static Type Checker for PythonFrom this comparison (https://github.com/microsoft/pyright/blob/main/docs/mypy-com...) it looks like Pyright fixes a load of issues that MyPy has. It also seems much closer to how TypeScript works (I have worked significantly more with TypeScript than typed Python and really like it)
Is there a reason not to go with Pyright and stick with MyPy?
In Pyright: Static Type Checker for PythonAn 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
In Pyright: Static Type Checker for PythonTo 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-com....
In Pyright: Static Type Checker for PythonShowing the 15 most recent of 16 sources. Enable JavaScript to search and browse every indexed mention.