I used Pytype at Google years ago and while it's well written and the team was responsive, ultimately Python is not well suited for type checking Python. It's compute intensive.
I think the Ty people at Astral have the correct idea, and hope it'll work out.
To be fair, even if there is/were a team, I don’t know that writing a new backend from scratch would be a good use of their time. pytype apparently started before mypy or any of the other Python type checkers existed. [1] But at this point there’s mypy, pyright, pyre/pyrefly, Ty, and probably more I’m not thinking of. It sounds more useful to collaborate with one of those existing projects than to write yet another new type checker.
Especially when, in my experience, each checker produces slightly different results on the same code, effectively creating its own slightly different language dialect with the associated fragmentation cost. In theory that cost could be avoided through more rigorous standardization efforts to ensure all the checkers work exactly the same way. But that would also reduce the benefit of writing a new type checker, since there would be less room to innovate or differentiate.
There is still a team within Google in charge of this space.
rhaps0dy · 1h ago
I've heard of `ty` too but recently I learned about Pyrefly, which is not in pre-production alpha, and is also Rust: https://pyrefly.org/
Is there a good reason to avoid using Pyrefly?
diggan · 1h ago
> Is there a good reason to avoid using Pyrefly?
Wouldn't the other way around be easier for finding good tools? Figure out what matters to you, inspect if the project fulfills those needs and then go with it after making sure it works well for you.
> 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.
I'm surprised Google still maintained their own solution for this for so long. The standard for statically type checking Python nowadays is mypy.
ipsum2 · 18m ago
Mypy is far too slow to type check a codebase like Google. That's why Facebook, Google, and Microsoft have/had their own solutions.
joshuamorton · 10m ago
Google, Facebook, and Microsoft all maintain(ed) independent non-mypy typecheckers for internal and external uses that aren't served by mypy.
The various features mypy didn't support include speed, type inference/graduality, and partial checking in the presence of syntax errors (for linter/interactive usecases and code completion).
kubb · 1h ago
Maybe they could do typechecking using an LLM agent? I'm sure they'd fund a team for that.
mudkipdev · 16m ago
This is the way
sito42 · 1h ago
astral bags another one
RS-232 · 54m ago
Is ty more mature than pyright or mypy?
I'm currently using pyright, but I'm going to migrate once ty and its vscode extension are given the "production ready" greenlight.
sito42 · 12m ago
at this stage I get very few false positives and it's so much easier to configure and use than pyright
ccbncvnnccvbj · 44m ago
Free fire 2018
delduca · 1h ago
Another abandoned project from Google? Not surprised. Never trust on Google.
silentsea90 · 59m ago
Pytype is used heavily inside Google so they bear the penalty likely more than you. Besides, py typing libraries is a dynamically changing landscape so it isn't anything out of the norm. Not everything is an abandoned project, and if anything Google abandons some projects well after the winners and losers are apparent eg Tensorflow.
md3911027514 · 1h ago
Pytype was cool before Python type annotations became widespread. It seems to me like the industry is naturally moving toward native type annotations and linters and away from static analyzers like Pytype and mypy.
underdeserver · 1h ago
Pytype and mypy check native annotations.
md3911027514 · 45m ago
Well yes but with native annotations the linter you’re already using can do a lot of the type checking work so for many teams it’s not worth it to add Pytype or mypy
I used Pytype at Google years ago and while it's well written and the team was responsive, ultimately Python is not well suited for type checking Python. It's compute intensive.
I think the Ty people at Astral have the correct idea, and hope it'll work out.
https://docs.astral.sh/ty/
In practice, there is no longer a pytype team at Google [https://news.ycombinator.com/item?id=40171125], which I suspect is the real reason for the discontinuation.
Especially when, in my experience, each checker produces slightly different results on the same code, effectively creating its own slightly different language dialect with the associated fragmentation cost. In theory that cost could be avoided through more rigorous standardization efforts to ensure all the checkers work exactly the same way. But that would also reduce the benefit of writing a new type checker, since there would be less room to innovate or differentiate.
[1] https://news.ycombinator.com/item?id=19486938
Is there a good reason to avoid using Pyrefly?
Wouldn't the other way around be easier for finding good tools? Figure out what matters to you, inspect if the project fulfills those needs and then go with it after making sure it works well for you.
Regardless, a comparison between the two was posted to HN not too long time ago: https://news.ycombinator.com/item?id=44107655
Pyrefly v0.29.0
Status : ALPHA
No comments yet
> 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
The various features mypy didn't support include speed, type inference/graduality, and partial checking in the presence of syntax errors (for linter/interactive usecases and code completion).
I'm currently using pyright, but I'm going to migrate once ty and its vscode extension are given the "production ready" greenlight.