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 5 days ago | parent | next [-]

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.

▲

zzzeek 5 days ago | parent [-]

pylance and others are great for IDE type checking as you go along, but when you ship your code off to the CI it's best to stick to mypy for the full automated run, since mypy is in some aspects a bit of the "reference implementation" for python typing (meaning, it's a good choice as the common denominator the code you ship will have with other code it interacts with).

	▲	ipsum2 5 days ago \| parent [-]
		Ideally yes, but there's conflicts between the type checkers.

▲

zem 5 days ago | parent | prev | next [-]

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 5 days ago | parent | prev [-]

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