ex-pytype dev here - we knew this was coming and it's definitely the right thing to do, but it's still a little sad to see the end of an era. in particular, pytype's ability to do flow-based analysis across function boundaries (type checking calls to unannotated functions by symbolically executing the function body with the types of the call arguments) has not been implemented by any of the other checkers (again for good reasons; it's a performance hit and the world is moving towards annotations over pure inference anyway, but I still think it's a nice feature to have and makes for more powerful checking).
as an aside, while I agree that bytecode-based analysis has its drawbacks, I think it's a tool worth having in the overall python toolbox. I spun off pycnite from pytype in the hope that anyone else who wanted to experiment with it would have an easier time getting started - https://github.com/google/pycnite
I have recently jumped onto the "write python tooling in rust" bandwagon and might look into a rust reimplementation of pycnite at some point, because I still feel that bytecode analysis lets you reuse a lot of work the compiler has already done for you.
almostgotcaught · 35m ago
> while I agree that bytecode-based analysis has its drawbacks
abstract interpretation of the bytecode like y'all were doing is the only way to robustly do type inference in python.
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.
there is a new python team, we met up with them at pycon and had some nice conversations. as a former pytype dev I will be the first to admit that maintaining it as a legacy project without the context of having developed it over the years would not have been a pleasant experience at all, but also pytype, while very powerful at what it did, definitely had some flaws that put it firmly in the last generation of type checkers.
the current generation (mostly ty and pyrefly right now, though major props to pyright for being ahead of the curve) is moving towards fast, incremental type checking with LSP integration, and pytype was never going to get there. it's fundamentally a slow, batch-based type checker, which will catch a lot of errors in your project, but which will never be usable as an incremental type checker within your ide. add that to the fact that it had a different philosophy of type checking from most of the other major checkers and you had users facing the issue that their code would be checked one way by pyright in the ide, and then a subtly different way by pytype in the CI pipeline.
I loved my time working on pytype, and I would like to see some of its features added to pyrefly, but it has definitely been superseded by now.
comex · 1h ago
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 · 2h 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 · 2h 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.
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 · 1h ago
Mypy is far too slow to type check a codebase like Google's. That's why Facebook, Google, and Microsoft have/had their own solutions.
zem · 49m ago
pytype had two features that made it uniquely suited to google's needs:
1. it had powerful type inference over partially or even completely unannotated code, which meant no one has to go back and annotate the very large pre-type-checking codebase.
2. it had a file-at-a-time architecture which was specifically meant to handle the large monorepo without trying to load an entire dependency tree into memory at once, while still doing cross-module analysis
there were a couple of attempts to get mypy running within google, but the impedance mismatch was just too great.
joshuamorton · 1h 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).
> 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 currently using pyright, but I'm going to migrate once ty and its vscode extension are given the "production ready" greenlight.
sito42 · 1h ago
at this stage I get very few false positives and it's so much easier to configure and use than pyright
denis- · 14m ago
ty still doesn't understand match + typing.assert_never pattern, last barrier for me to switching.
mgaunard · 14s ago
tl;dr please use pyright instead
ccbncvnnccvbj · 1h ago
Free fire 2018
delduca · 2h ago
Another abandoned project from Google? Not surprised. Never trust on Google.
silentsea90 · 2h 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 · 2h 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 · 2h ago
Pytype and mypy check native annotations.
md3911027514 · 1h 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
as an aside, while I agree that bytecode-based analysis has its drawbacks, I think it's a tool worth having in the overall python toolbox. I spun off pycnite from pytype in the hope that anyone else who wanted to experiment with it would have an easier time getting started - https://github.com/google/pycnite
I have recently jumped onto the "write python tooling in rust" bandwagon and might look into a rust reimplementation of pycnite at some point, because I still feel that bytecode analysis lets you reuse a lot of work the compiler has already done for you.
abstract interpretation of the bytecode like y'all were doing is the only way to robustly do type inference in python.
> https://github.com/google/pycnite
there's also https://github.com/MatthieuDartiailh/bytecode which is a good collection
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.
the current generation (mostly ty and pyrefly right now, though major props to pyright for being ahead of the curve) is moving towards fast, incremental type checking with LSP integration, and pytype was never going to get there. it's fundamentally a slow, batch-based type checker, which will catch a lot of errors in your project, but which will never be usable as an incremental type checker within your ide. add that to the fact that it had a different philosophy of type checking from most of the other major checkers and you had users facing the issue that their code would be checked one way by pyright in the ide, and then a subtly different way by pytype in the CI pipeline.
I loved my time working on pytype, and I would like to see some of its features added to pyrefly, but it has definitely been superseded by now.
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
Pyrefly spits put around 200 errors for the same codebase.
Most errors are related to SQLAlchemy.
No comments yet
Google lays off its Python team | Hacker News https://news.ycombinator.com/item?id=40171125
1. it had powerful type inference over partially or even completely unannotated code, which meant no one has to go back and annotate the very large pre-type-checking codebase.
2. it had a file-at-a-time architecture which was specifically meant to handle the large monorepo without trying to load an entire dependency tree into memory at once, while still doing cross-module analysis
there were a couple of attempts to get mypy running within google, but the impedance mismatch was just too great.
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).
> 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
Developers: mypy, pyright, pyrefly, ty, pypy, nogil, faster-python, sub-interpreters, free-threading, asyncio, ...
I'm currently using pyright, but I'm going to migrate once ty and its vscode extension are given the "production ready" greenlight.