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.
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.
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.
Is there a good reason to avoid using Pyrefly?
Pyrefly spits put around 200 errors for the same codebase.
Most errors are related to SQLAlchemy.
Perhaps you should do the upgrade (https://docs.sqlalchemy.org/en/20/changelog/whatsnew_20.html...) and try again?
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
I agree, and Pyrefly seemed good; I was just wondering why people don't mention it.
Thank you for the comparison thread and post, I've read it and found it useful! Thanks to that post I know ty has a "gradual typing" philosophy, which I disprefer.
> /!\ Warning
> ty is in preview and is not ready for production use.
> We're working hard to make ty stable and feature-complete, but until then, expect to encounter bugs, missing features, and fatal errors.
Google sucks.
I'm currently using pyright, but I'm going to migrate once ty and its vscode extension are given the "production ready" greenlight.
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).
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.
> 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
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 know Go and Rust are the belles du jour, but this kind of thing really hampers integrators' ability to support platforms other than x86-64 and armv8. In my particular case, it results in me being unable to build software that depends on pyca/cryptography on platforms like s390x, which makes me sad. It also makes development environment management, including CI/CD pipeline maintenance, that much more complicated. It was already bad enough when I was trying to compile binary distributions on Windows, and that was just with the Visual C++ toolchain mess that is the Microsoft development experience.
I used to be very much in the "write your language tools in the language and the community will contribute" camp, but astral has really shown what a big difference pure speed can make, and I now have more of a "write tools in rust and ideally make sure they also expose libraries that you can call from python" mindset.
That doesn't feel great to me.
Google lays off its Python team | Hacker News https://news.ycombinator.com/item?id=40171125
Developers: mypy, pyright, pyrefly, ty, pypy, nogil, faster-python, sub-interpreters, free-threading, asyncio, ...
md3911027514•8h ago
underdeserver•8h ago
md3911027514•7h ago