pytype dev here - thanks for the kind words :) whole-program analysis on unannotated or partially-annotated code is our particular focus, but there's surprisingly little dark PLT magic involved, and you certainly don't need to be an academic type theory wizard to understand how it works. our developer docs[1] have more info, but at a high level we have an interpreter that virtually executes python bytecode, tracking types where the cpython interpreter would have tracked values.
it's worth exploring some of the other type checkers as well, since they make different tradeoffs - in particular, microsoft's pyright[2] (written in typescript!) can run incrementally within vscode, and tends to add new and experimentally proposed typing PEPs faster than we do.
[1] https://github.com/google/pytype/blob/main/docs/developers/i...
[2] https://github.
microsoft
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, 4:00:59 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
14 sourcesIn Ruff – a fast Python Linter written in Rust
Woah, Pyright is written in Node? And it has its own [parser](https://github.com/microsoft/pyright/blob/b74be3b2cb2c5d35b9...)? That's really interesting. I wonder how it compares to Mypy on speed.
> The main thing that eventually forced decision was a flaky (depends on cache) mypy crash using paramspecs half a year ago. At time paramspec support was still in progress and there’s a good chance that specific issue is fixed.
I actually think I ran into this exact issue (ParamSpec-related, only fails when reading from cache, etc.), which led me to pin a Mypy development version for a while and was fixed recently.
In Using Mypy in ProductionPainpoint with type annotations: not being able to reuse "shapes" of data, e.g. struct-like fields such as TypedDict, NamedTuple, dataclasses.dataclass, and soon *kwargs (PEP 692 [1]) via TypedDict.
Right now, there isn't a way to load up a JSON / YAML / TOML into a dictionary, upcast it via a `TypedGuard`, and pass it into a TypedDict / NamedTuple / dataclass.
dataclasses.asdict() or dataclasses.astuple() return naïve / untyped tuples and dicts. Also the factory functions will not work with TypedDict or NamedTuple, respectively, even if you duplicate the fields by hand [2].
Standard library doesn't have runtime validation (e.g. pydantic [3]). If I make a typed NamedTuple/TypedDict/dataclass with `apples: int`, nothing is raised in runtime when a string is passed.
Other issues you may run into using mypy:
- pytest fixtures are hard. It's
Read the rest
repetitious needing to re-annotate them every test.
- Django is hard. PEP 681 [4] may not be a saving grace either [5]. Projects like django-stubs don't give you completions, it'd be a dream to see reverse relations in django models.
- Some projects out there have very odd packaging and metaprogramming that make typing and completions impossible: faker, FactoryBoy.
[1] https://peps.python.org/pep-0692/
[2] https://github.com/python/typeshed/issues/8580
[3] https://github.com/pydantic/pydantic
[4] https://peps.python.org/pep-0681/
[5] https://github.com/microsoft/pyright/blob/8a1932b/specs/data...
Python is statically typed though. [1][2][3][4]
These aren't just some third-party tools bolted on. The type annotation syntax is built into the language[5] and standard library[6][7].
I personally find static typing to be more trouble than it's worth most of the time. Industry typing metalanguages are not expressive enough to deal with even fairly basic real-world programs and force you to write bad code to work around the type checker's stupidity. And, of course, you still have to write tests. Maybe someday they'll catch up to Idris. Python's static typing is no better, but at least it allows you to turn it off when it's not worth it.
[1]: https://github.com/microsoft/pyright
[2]: https://github.com/python/mypy
[3]: https://github.com/google/pytype
[4]: https://github.com/facebook/pyre-check
[5]: https://peps.python.org/pep-3107/
[6]: h
Read the rest
One aspect of Pyright that seems decidedly not better is the 651 NPM dependencies [1] it apparently drags along.
[1] https://github.com/microsoft/pyright/blob/main/package-lock....
In What's New in Python 3.11?Just for balance, Pylance is proprietary but the core of it is the Pyright library which is completely open (see: https://github.com/microsoft/pyright).
It would be nice if they were more transparent about the differences between the two and why Pylance is closed. There are a few github issues where Microsoft PMs basically stonewall the community with very little info.
In Despite best efforts .NET is still not an open platformpyright is a command line program https://github.com/microsoft/pyright
in my experience it's a far better type checker than mypy, which tends to silently not check things without you ever realising
In Python’s “type hints” are a bit of a disappointment to meI disagree diametrically with both the general sentiment of the article, and every major point that was made in it.
Every point in this blog post strikes me as either (1) unaware of the tooling around python typing other than mypy, or (2) a criticism of static-typing-bolted-on-to-a-dynamically-typed-language, rather than Python's hints. Regarding (1), my advise to OP is to try out Pyright, Pydantic, and Typeguard. Pyright, especailly, is amazing and makes the process of working with type hints 2 or 3 times smoother IMO. And, I don't think points that fall under (2) are fair criticisms of type *hints*. They are called hints for a reason.
Otherwise, here's a point-by-point response, either recommending OP checks out tooling, or showing that the point being made is not specific to Python.
> type hints are not binding.
There are projects [0]
Read the rest
[1] that allow you to enforce type hints at runtime if you so choose.
It's worth mentioning that this is very analogous to how Typescript does it, in that type info is erased completely at runtime.
> Type checking is your job after all, ...[and that] requires maintenance.
There are LSPs like Pyright[2] (pyright specifically is the absolute best, IMO) that report type errors as you code. Again, this is very very similar to typescript.
> There is an Any type and it renders everything useless
I have never seen a static-typing tool that was bolted on to a dynamically typed language, without an `Any` type, including typescript.
> Duck type compatibility of int and float
The author admits that they cannot state why this behavior is problematic, except for saying that it's "ambiguous".
> Most projects need third-party type hints
Again, this is a criticism of all cases where static types are bolted on dynamically typed languages, not Python's implementation specifically.
> Sadly, dataclasses ignore type hints as well
Pydantic[3] is an amazing data parsing library that takes advantage of type hints, and it's interface is a superset of that of dataclasses. What's more, it underpins FastAPI[4], an amazing API-backend framework (with 44K Github stars).
> Type inference and lazy programmers
The argument of this section boils down to using `Any` as a generic argument not being an error by default. This is configurable to be an error both in Pyright[5], and mypy[6].
> Exceptions are not covered [like Java]
I can't find the interview/presentation, but Guido Van Rossum specifically calls out Java's implementation of "exception annotations" as a demonstration of why that is a bad idea, and that it would never happen in Python. I'm not saying Guido's opinion is the absolute truth, but just letting you know that this is an explicit decision, not an unwanted shortcoming.
[0] https://github.com/RussBaz/enforce
[1] https://github.com/agronholm/typeguard
[2] https://github.com/microsoft/pyright
[3] https://pydantic-docs.helpmanual.io
[4] https://github.com/tiangolo/fastapi
[5] https://github.com/microsoft/pyright/blob/main/docs/configur...
[6] https://mypy.readthedocs.io/en/stable/config_file.html#confv...
MyPy isn’t the only checker of course, there’s also Microsoft’s Pyright, among others. Pyright is fast and natively integrated in Microsoft’s Pylance VSCode extension, so these days I use Pyright’s type checking in real time even when I can’t be bothered to set up MyPy (no difficult, just not important for, say, <1000 line scripts). I default to strict mode for stuff that’s not too dynamic.
https://github.com/microsoft/pyright
https://marketplace.visualstudio.com/items?itemName=ms-pytho...
In Python’s “type hints” are a bit of a disappointment to me>most people use the crap one (Mypy)
idk, I wouldn't go this far. Mypy is slow, but it's probably the most correct, and it allows for configurations pyright refuses to. For instance, the maintainers won't add an option to allow variable redefinition/shadowing, seemingly because they don't understand the difference between a variable and a binding (https://github.com/microsoft/pyright/discussions/2441). As for Pyre, last I checked it had a lot of false positives that Mypy doesn't.
Besides all that, some people want to use a checker that isn't exclusively developed by a huge company (Microsoft, Google or Facebook).
In First look: adding type annotations to JavaScriptPyright – Static type checker for Python
1 points · Open discussionNot to be confused with https://github.com/microsoft/pyright and dozens more smaller projects.
In Pyrite – open-source video conferencingNot to be confused with https://github.com/microsoft/pyright
In Pyrite – open-source video conferencing