An Update on Pytype

[zem]

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]

> 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.

> https://github.com/google/pycnite

there's also https://github.com/MatthieuDartiailh/bytecode which is a good collection

[xenophonf]

> I have recently jumped onto the "write python tooling in rust" bandwagon

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.

[lostmsu]

I worked on https://github.com/Microsoft/PTVS (not being in MSFT) around 2019 so I know they did type check calls across function boundaries.

[librasteve]

why not just go with a language that has gradual typing built in - eg raku

[underdeserver]

I think this is for the best.

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/

[zhikanbumai]

In theory, nothing prevents the pytype team at Google to develop a new backend in a different language.

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.

[rhaps0dy]

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?

[LtWorf]

I'm personally just staying away from startups anywhere in my dependencies.

[froh]

in 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

[yegle]

fwiw the original pytype team was laid off as part of laying off the Python team last year.

Google lays off its Python team | Hacker News https://news.ycombinator.com/item?id=40171125

[jdlyga]

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]

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]

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]

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]

Maybe they could do typechecking using an LLM agent? I'm sure they'd fund a team for that.

[mudkipdev]

This is the way

[randomNumber7]

Just let it interpret the python code /S

[sito42]

astral bags another one

[RS-232]

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.

[mgaunard]

tl;dr please use pyright instead

[delduca]

Another abandoned project from Google? Not surprised. Never trust on Google.

[silentsea90]

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.

[wiseowise]

DAE GOole killing another project?!!! (Apparently maintaining something completely free of charge for 13 years is not enough for online cannibals)

[instig007]

Scala 3: exists, https://docs.scala-lang.org/scala3/book/scala-features.html

Developers: mypy, pyright, pyrefly, ty, pypy, nogil, faster-python, sub-interpreters, free-threading, asyncio, ...

[vovavili]

This would have been a fair point had Scala 3 supported Python's packages and was compatible with Python's tooling. At the very least until Mojo is mature and open-sourced, there are simply no alternatives to pouring time and effort into making Python a better language.

[ivanjermakov]

Both python language and its ecosystem are such a mess. Imagine the amount of human hours spent on tooling development trying to fix fundamental flaws in a language design.

[md3911027514]

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]

Pytype and mypy check native annotations.