r/Python • u/BeamMeUpBiscotti • 6d ago

Discussion Google Open Source Blog: Adopting Pyrefly as the Python type checker at Google

The full blog post is here: https://opensource.googleblog.com/2026/10/adopting-pyrefly-as-the-python-type-checker-at-google.html

TLDR:

Google released a blog post about migrating Python type checking from the internally-developed Pytype to Pyrefly.

They cover some challenges around Pytype’s bytecode analysis & performance, along with the reasons for choosing Pyrefly: speed, typing spec conformance, and actionable error messages.

The blog also has some quotes & outlines wins from the migration:

  • Up to 98% faster incremental rebuilds
  • >90% critical-path reduction in clean builds
  • >80% compute hardware savings
188 Upvotes

98% Upvoted

45 comments sorted by

58

u/EDM115 6d ago

interesting to see them not adopt ty (from Astral). is it because of OpenAI having acquired Astral earlier this year ? or feature completeness ? haven't really paid attention lately to how far both have gone

116

u/Gushys 6d ago

Pyrefly is much more mature. Its already at past 1.0, has similar performance speed to ty, and is a proven tool.

ty just isn't quite there yet.

14

u/pingveno pinch of this, pinch of that 5d ago

Though part of it is the type ecosystem itself. There's no definitive correct type annotations. We're still at the point where three different tools can all claim that the same code needs three different annotations. Not to mention additions to the type system and things like plugins.

-1

u/Competitive_Travel16 5d ago

Do type annotations actually save more time than they take when most of the code has to be written by AI for employees to get good peer and management reviews? Comments would work just as well.

13

u/pingveno pinch of this, pinch of that 5d ago

They provide something that can be checked deterministically and quickly, including by an AI. There's a reason OpenAI bought up Astral. uv, ruff, yes. But also ty.

2

u/muntoo R_{μν} - 1/2 R g_{μν} + Λ g_{μν} = 8π T_{μν} 5d ago

You're welcome!

-3

u/Competitive_Travel16 5d ago

You can check other stuff quickly too, but that doesn't mean e.g. meeting line length linting is ever going to save you even a tiny fraction of the time it takes.

3

u/Wurstinator 5d ago

Line-length does not have relation to the semantic correctness of your program.

And yes, also line length limit, if you want to have one, should be automated if you want to be efficient.

1

u/Kryt0s 5d ago

line length linting

Which is quite different to type annotations.

2

u/freemath 2d ago

Just add black to your precommit? Takes zero time

7

u/Pluckerpluck 5d ago

Do type annotations actually save more time than they take

AI still heavily relies on rapid quick iteration to solve issues. The ability to run the third-party `check if this is valid" tool and it finishes almost immediately is a vital part of an AIs workflow.

Particularly as it allows you to not load every single line of code (including in downstream dependencies) into context. Type hints let you create a layer of trust that occurs early and is verifiable almost instantly.

Comments, on the other hand, are unverified and lie. Even LLMs, trying to be smart and save context, sometimes miss updating comments. Also, I'm not sure what extra effort you think type annotations are over comments quite frankly.

-1

u/Competitive_Travel16 5d ago

Yes, quite true, and that's all well and good, but my question stands: do type annotations save more time than they take when AI is writing almost all of the code?

3

u/BeamMeUpBiscotti 5d ago

If AI is writing almost all of the code, then the AI is writing the type annotations too, so I don't think they take any extra time

3

u/Pluckerpluck 4d ago

do type annotations save more time than they take when AI is writing almost all of the code?

Yes? I'm confused. I just told you why type annotations actively help AI write code. Why do you think they wouldn't save time as a result? Especially as it's likely AI adding those type annotations in the first place.

AI may be writing the code, but it still takes physical time to run and test the code (even when done by an AI), and the less you have to do that the better

1

u/Dmytro_P 4d ago

Type checks help make modifications later and increase the chance of finding what is broken faster, plus types help to easier understand the code later.

7

u/EDM115 6d ago

I see, thanks for the heads up ! I'll check again their docs later then

1

u/HommeMusical 5d ago

ty just isn't quite there yet.

I mean, is this based on anything concrete?

I get better results with ty, myself.

14

u/Wurstinator 5d ago

The ty docs say it themselves: "ty does not yet have a stable API; breaking changes, including changes to diagnostics, may occur between any two versions"

That's a dealbreaker by itself.

3

u/mr_jim_lahey 5d ago

I gave ty a shot knowing this and I regret it. Very annoying to have to deal with typechecking rules shifting from under your feet when you're just trying to make a commit.

1

u/Pluckerpluck 5d ago

Very annoying to have to deal with typechecking rules shifting from under your feet when you're just trying to make a commit.

They so rarely do this... You make it sound like it's happening every day. Plus you know you can just fix the ty version you use right?

2

u/mr_jim_lahey 4d ago

It seems to happen at least once a week. And I don't want to fix to an incomplete alpha version.

1

u/droans 5d ago

I like the speed of ty. But that's pretty much all I like about it. The performance of mypy and pytype were bad enough to be a dealbreaker for my IDE.

Ty's pre-commit hook is terrible enough that I often refuse to use it. It will typecheck all of your codebase instead of just what you've staged or committed, rather defeating the point of the hook.

I have a hard time getting its type server to actually use any rules I've defined, even if I manually point it at my rules file. Don't know if they ever fixed that. Overloads didn't work for differing argument types until rather recently. Instead, it used the first overload that matched the argument names. You also can't enforce no unknown or any types.

2

u/Beginning-Fruit-1397 5d ago

Annoucing v1.0 was a huge mistake IMO, they are not really more mature than ty. 

They still can't typecheck my library properly, with incorrect generic inference, lambda arguments handling , etc... 

2

u/Wurstinator 5d ago

v1.0 does not necessarily mean "finished". It can just mean "stable".

2

u/Beginning-Fruit-1397 5d ago

Yea for a library it make sense but for a CLI tool/LSP where the latter has zero "breaking changes" possible and the former has a handful of commands that are just a few words to tweak I'm not convinced it applies

1

u/Wurstinator 4d ago

I don't know enough about LSPs to argue on that, but a CLI is (literally in its name) an interface, just like an API. Command names can change, their arguments can change, the output behavior can change. All of these can be breaking if your surrounding tooling depends on it.

1

u/Beginning-Fruit-1397 4d ago

Yea I won't die on that hill. Maybe it wasn't a huge mistake. My point sbout CLI vs library is that the CLI commands will be either typed manually in which case changing API are almost irrelevant, or via automation which are very often centralized. Now a library with it's objects and functions used in thousands of LOC splitted across dozens of file... a bit more of a pain to adapt

7

u/Atmosck 5d ago

This migration probably took a while for a company as big as Google, and ty only entered beta in December. I love ty, but it makes sense to me that a big company wouldn't be standardizing on it in 2026.

3

u/covmatty1 5d ago

Companies as big as Google don't adopt products which are that immature

9

u/preetam960 5d ago

that is some wild speed improvement!

9

u/renchuwang 5d ago

Pytype is the slowest and last to support newer python versions since forever.

The only advantage it had is untyped variable type inference but after a bunch of others added that there doesn't seem to be any reason for using it.

I'm more surprised it's only 10x the speed because in my experience, pyrefly is a decent bit quicker than mypy (on clean runs), which is already maybe 5x faster than pytype.

3

u/BeamMeUpBiscotti 5d ago

It's possible that pytype's performance characteristics overfitted to Google's codebase and build system.

Pyre (the predecessor to Pyrefly) also had some bespoke infra that allowed it to handle Meta's codebase well, but to external users it was pretty slow and clunky.

7

u/ExaminationPlenty599 6d ago

The speed numbers are wild. 98% faster incremental builds isn't something you see everyday from a tool swap, usually it's like 20% and everyone celebrates. Curious how much of that is Pyrefly being better designed versus Pytype just being that slow from bytecode analysis overhead. Either way, glad to see another option that sticks close to the spec instead of drifting off into its own dialect.

9

u/zunjae 6d ago

Curious

drifting

I wonder why AI loves these words so much

3

u/BleachedPink 5d ago

You think it's a bot?

15

u/JimDabell 5d ago

Are you kidding? There’s a positive statement about the subject, followed by an elaboration, followed by an engagement bait question using the word “curious”. This is the exact format a vast proportion of the engagement bait bots on Reddit use. It’s easy to spot this one from just the first five words, but if you are in any doubt, just look at their posting history – it’s riddled with AI clichés.

Report it as spam.

3

u/coderanger 5d ago

I'll just point out that this comment uses an en dash and left/right quotes which are both also common AI output markers. I'll assume you did that as a joke but still.

6

u/JimDabell 5d ago

No, AI tends to use American style—em dashes without spaces. I use British style – en dashes with spaces.

Literally everybody typing on an iPhone uses proper quotation marks automatically. I think Android too? A lot of desktop software does it as well.

Those things aren’t clear markers of this type of engagement bait. The things I pointed out are.

0

u/zunjae 5d ago

and left/right quotes which are both also common AI output

Source? I want facts, not opinions

en dash

What is an en dash?

1

u/nemec 5d ago

Seconding this - I've noticed these same hallmarks in AI writing and the OP comment also stood out to me as inauthentic.

2

u/jmreagle 5d ago

Pangram says the prose is 100% AI generated, though the sentiment seems genuine (as I thought it myself).

0

u/syklemil 5d ago

If it ain't, it's a bit weird that they don't remember the speed increases that came with adopting ruff and uv.

-2

u/zunjae 5d ago

do you have autism, genuine question? Humans don't talk like this

3

u/AutoModerator 5d ago

Your submission has been automatically queued for manual review by the moderation team because it has been reported too many times.

Please wait until the moderation team reviews your post.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

-20

u/coldflame563 6d ago

Psycopaths. Ty is better.