1. https://docs.astral.sh/ty/
2. https://github.com/microsoft/pyright
3. https://github.com/python-lsp/python-lsp-server
4. https://github.com/palantir/python-language-server
In Claude Code gets native LSP supportmicrosoft
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 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 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
68 sourcesIt also inherits the unfortunate attitude of Pyright that it will warn against idiomatic Python (EAFP) in favour of non-idiomatic Python (LBYL):
https://github.com/microsoft/pyright/issues/1739
https://docs.python.org/3/glossary.html#term-EAFP
https://docs.python.org/3/glossary.html#term-LBYL
In Pyrefly: Python type checker and language server in Rustin the related FAQ
https://github.com/google/pytype/issues/1925
they point explicitly to the future:
> What alternatives can I consider?
There are four Python static type checkers that can be considered: mypy and Pyright have been released to the community for a while and have well established user bases. Pyrefly, ty were announced recently at PyCon US 2025 and are in active development stage in the current time of August 2025 when this was written.
mypy - https://github.com/python/mypy
Pyright - https://github.com/microsoft/pyright
Pyrefly - https://github.com/facebook/pyrefly
ty - https://github.com/astral-sh/ty
In An Update on PytypeThe current major type checkers, mypy and pyright, are also based on the same PEPs, but you can still see differences between them. For example, my codebase passes pyright in strict mode, but mypy results in a bunch of type errors. I'd expect pyrefly and ty to be slightly different from each other.
See also:
https://github.com/microsoft/pyright/blob/main/docs/mypy-com...
https://htmlpreview.github.io/?https://github.com/python/typ...
In Pyrefly: A new type checker and IDE experience for PythonGreat, but how does it compare to Pyright on the utility / performance curve? Pyright is mature and already very fast.
https://github.com/microsoft/pyright
In Ty: A fast Python type checker and language serverIt has warnings that steer you away from idiomatic Python towards less idiomatic Python.
Idiomatic Python favours EAFP (Easier to Ask Forgiveness than Permission) over LBYL (Look Before You Leap), so you might write something like this when using TypedDicts:
try:
foo = bar["baz"]["qux"]
...
except KeyError:
...
Pyright warns you about this and pushes you to write this:
if "baz" in bar and "qux" in bar["baz"]:
foo = bar["baz"]["qux"]
...
else:
...
They identified this as a bug and fixed it, then changed course and decided to reinstate the behaviour. So if you want to write idiomatic Python, you need to disable typechecking TypedDicts.
— https://github.com/microsoft/pyright/issues/1739
Now if this were a linter then I would understand. But a type checker should not be opinion
Read the rest
ated to the point of pushing people not to use idiomatic Python.
This is a good summary: 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.
In "We're building a new static type checker for Python"I think that 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
Read the rest
just ignoring checks.
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-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, refa
Read the rest
ctoring 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.
We have it already: https://github.com/microsoft/pyright
In Ruff: Python linter and code formatter written in RustPyright is billed as a "static type checker" but its a full-blown language server (which pylance is built on). I've used both pylance and pyright and frankly I haven't seen any benefit going up to pylance. Pyright is under the MIT license so it can be used for anything: https://github.com/microsoft/pyright/blob/main/LICENSE.txt
In Multilspy: Building a common LSP client handtuned for all Language serversdisclaimer: I don't work on big codebases.
Pylance with pyright[0] while developing (with strict mode) and mypy[1] with pre-commit and CI.
Previously, I had to rely on pyright in pre-commit and CI for a while because mypy didn’t support PEP 695 until its 1.11 release in July.
[0] -- https://github.com/microsoft/pyright
[1] -- https://github.com/python/mypy
In Python 3.13.0 Is ReleasedThere is also the rarely mentioned pytype from Google, written in Python. And pyright from Microsoft is written in Typescript, pyre at Facebook in OCaml. Last time I checked, these had better type inference algorithms (Hindley-Milner?) than mypy.
https://github.com/google/pytype
https://github.com/google/pytype
https://github.com/microsoft/pyright
In GIL Become Optional in Python 3.13Showing the 15 most recent of 68 sources. Enable JavaScript to search and browse every indexed mention.