Pyrefly: A new type checker and IDE experience for Python
engineering.fb.com
engineering.fb.com
So watch out, or this will become like Atom or Flow, an internal competitor of a technology that is surpassed by the more popular external open source version, leaving the directors/vps muttering to themselves "It's too bad that this team exists at all. Could we get rid of them and just switch to the open source stuff?"
Perhaps just something for the manager (Aaron Pollack?) to keep an eye on....
I’m working on Pyrefly now, but worked on Flow for many years before. For what it’s worth, we are taking a different approach compared to Flow and have explicitly prioritized open source and community building, something I know we both care a lot about.
Of course, nothing is guaranteed and we’ve seen plenty of volatility in bigco investments to infra lately, but I do believe we’re starting this journey on the right foot.
Cheers, Sam
Given the change velocity of internal tooling you can understand why owning your own project makes sense here.
* Autocompletion
* Type checking
* Syntax highlighting
* Lack of runtime string parsing
Tagged template literals don't.
tagged template literals can have all of these, some already exist¹ and doesn't need a build step.
1. https://marketplace.visualstudio.com/items?itemName=bierner....
But yeah other than that you're right. I'm just talking about first-class VS Code support. Which to me means a lot.
Vut inside an IDE or an LSP, tagged literal strings need quite a bit more special support than JSX, AFAICT.
But they still don't have all the first-class features of JSX.
I don't think this plugin works with type checking for instance.
They're all features in the jsx ecosystem that are provided by other libs, which are often preconfigured with projects utilizing jsx.
I did miss a lot of the tooling I've gotten used to the last time I made a weekend project utilizing lit webcomponents for sure, but I believe the people advocating for it usually rejoice in having less tooling in their development pipeline - it's just a fundamental disconnect between people that have learned and gotten used to current frontend development and people that don't really want to bother with it, looking for simpler solutions with less moving parts.
You mean strings with custom non-standard syntax and weird rules of hooks, sorry, directives?
Did you see better speedups over Pyre? Aka did I leave stuff on the table…
I didn’t know about the Rust-based Hack checker— that’s really cool!
But of course unless parsing and manipulating JSON is your bottleneck, Pydantic is great, too.
"Today we’re releasing Pyrefly as an alpha. At the same time, we’re busy burning down the long-tail of bugs and features aiming to remove the alpha label this Summer. "
That's kind of the whole appeal of Astral. I know Python better than Rust, but it's a lot easier for me to hack on Rust projects. The whole appeal of Astral is that they want to bring Rust-quality tooling to Python.
That static typing is nice, I wonder if it's going to catch on one day.
The amount of energy spent trying to bend dynamically types languages into being real ones is just comical. Even the standard library is barely typed, so they give no fucks https://github.com/python/cpython/blob/v3.13.3/Lib/re/__init...
What does it accept? Who knows. What does it return? Don't worry about it
The big thing for me is that most Rust projects are statically(ish) compiled (like go) and only need a `cargo build`. No venvs or pip commands or node/npm/nvm or make, etc.
And let me just say what an absolutely stellar job the rustc authors have done with the error messages. Just out of this world thoughtful. I have not yet gotten on board with their compile time vs safety and insight tradeoff, but I can see why they chose those two axes
It’s like laughing at photographers for not using the “rule of thirds” sometimes.
I'm not saying Rust has exclusivity here, I'm only explaining why I like to know a project was written in Rust.
If you would enjoy further support, install stubs from typeshed.
It is exactly as I said, it's not just strings
$ python3.12 -c '
import re
pat = re.compile("who knew")
ma = re.match(pat, "who knew types matter")
print(ma)
'
<re.Match object; span=(0, 8), match='who knew'>
I guess it's good we're all using LLMs nowadays, since in general computers no read so good, that's why we write in specialized languages for their benefit. That would include this fancy new thing I've heard about where one writes down what the input and output domains are for functions
> Types were not entered directly into stdlib source for historical reasons.
Historical reasons defeats the purpose of having git tags, to say nothing of them having several concurrent branches named after the various release trains. I mean, historically print was a keyword, but you sure don't see them from __future__ import print_statement all over the 3.12 tree now do you? It's because they DGAF preferring there to be seemingly unlimited aftermarket tooling to try and drag python3000 into the 21st century
> If you would enjoy further support, install stubs from typeshed.
While trying to dig up whatever a sane person would use to "install stubs" -- because it for damn sure isn't $(pip install typeshed) -- I learned that you were even more incorrect - it accepts bytes, too https://github.com/python/typeshed/blob/9430260770b627c04313...
Anyway, they also go out of their way to say "don't install typeshed" and I guess that's why they don't have any git tags because releases are for children
Normally you'd use `pattern.match(string)` in that case.
They said specifically more than once that they're not going to change (almost) every line in the repo for any reason, and not only to types but other syntax improvements. Probably to keep git blame intact and avoid introducing new bugs.
Honestly, this reads as an obsession with theoretical concerns.
This was actually the subject of a study at the University of Waterloo:
> We find that despite concerns about ease of use, first-time contributors to Rust projects are about 70 times less likely to introduce vulnerabilities than first-time contributors to C++ projects.
You can say that about any languages that you yourself know, or other people know. There are beautiful codebases in many other languages, and awful ones in the same languages.
If your Rust codebase has a lot of unwraps and lifetime annotations (among other things), I will probably not find it a joy to contribute to it, at all.
No, I'm saying that Rust was easier to hack on and contribute to (on my own) when I had never written any Rust before. Rust (and almost Go) is the only language I can confidently say this about. It's not even in my top 5 strongest languages now, but I still stand by this.
E.g. Look at the build instructions for Gimp and all its prerequisites: https://developer.gimp.org/core/setup/build/
Very normal C++ project, ~500 words of instructions. Once I started thinking about using a chroot to fix dependency issues after I'd already built bebl and gegl, I gave up, because I ran out of free time. It didn't matter how much C++ I knew.
Rust projects, comparatively, almost never demand that. It's almost always just `cargo build`, with some rare exceptions (e.g. The one exception I know of for which this is not true for is Graphite, which is a web app and also uses npm. )
I do not like C++ projects, they are behemoths, slow to compile, and C++ continues getting so much bullshit bolted on top of the language. It is extremely complicated, at least for me.
Most of my projects - regardless of language - has extremely simple build instructions, no matter how large it is.
As for GIMP, "meson" and "ninja" is not too bad, I have come across projects with much worse build instructions, but I agree, it is leaning towards "complicated".
> Once I started thinking about using a chroot to fix dependency issues after I'd already built bebl and gegl
Been there, done that. I remember compiling GCC myself, it was not as straightforward as, say, LLVM + clang. I think the issue is not with the language itself, however, but the developers who do not simplify the build process.
This generally fails miserably, in my experience. It's normally a dance of error: libfoo missing, followed by install (which is generally only straightforward on linux), followed by libbar is missing etc.
Don't get me wrong, I have built lots of non-trivial C projects, but it's not straighforward at all (maybe if you always work in C it's easier).
The time I spend doing things is much more valuable than the time my computer spends doing things.
I can only speak for why I like to know a project is written in Rust. I didn't add the build time because I didn't care.
Rust is both CPU- and memory-efficient, quite unlike Python. (It could have been OCaml / Reason, or Haskell, they are both reasonably fast and efficient, and very convenient to write stuff like typecheckers in. But the circle of possible contributors would be much narrower.)
A type checker is performance critical code. You can watch how Pylint, just a linter, written in Python, lints your source code line by line. It's so slow it can take 30 seconds to update the linting after you change some lines.
Open source Rust is still review able.
A lot of people. Correct or not, I think "written in rust" have become synonymous with "very much faster than the alrernatives" in the pyrhon community.
I genuinely chose the language for one of my projects based on this reasoning. I want to be in the nice UX gang.
If one is a "purist", the idea of non-python tool involvement may dissatisfy.
Scare-quoting "purist", given the general lack thereof anywhere in Open Source, python itself being a case in point.
I hope Mojo can offer something here
(C, to my mind, should be eventually phased out from application programming altogether, so N would be 2, but it's a loooooong process; Python may become a legacy language before it converges.)
I am not holding out much hope for Mojo because it feels deeply embedded in the AI/LLM hype space instead of being presented to Python devs outside of that niche as a useful language extension in its own right.
Mojo right now is not much better, but I've seen Python compatibility factor into the language design and semantics again and again. It is not enough to be a language that looks like Python, like Nim, things also have to behave the same when the semantics of static typing allows.
Mojo is not deeply embedded in the AI/LLM hype, there is nothing in the language that is targeted specifically for AI. The standard Library has a GPU package for general-purpose gpu programming, but that isn't AI specific.
Alternatively if you try to search for the Github repo for Mojo, you end up here: https://github.com/modular/modular Which is all about control planes and k8s and AI something something. Sure, it seems this is just a monorepo under which one of the folders actually is Mojo itself, but this packaging does not inspire confidence that the creators of the language are interested in building a language that exists outside of their ecosystem.
In the future that will change, Modular is aiming to get it ready for open-source by Q4 2026. By then it'll have full Python interop, so you can use existing Python packages in Mojo. Unlike Rust/Julia, Mojo does not have to bootstrap a community and ecosystem from scratch.
This is going to sound elitist, but if you can grok Python but can't grok Rust then you probably shouldn't be writing ecosystem tools for Python anyway.
I had gotten so messed up trying to put together a quicky hobby-type program to create a data structure of perhaps a hundred data items in various overlapping and inter-related hierarchies, tuples, dicts, and lists akimbo, that I gave up on it about 10 days ago. I hypothecated that bondage and discipline might be the way to control the confusion, so I'm rewriting, using SQLite for the dataflow from function to function, lots of little tables and no optional fields. Can anyone opine on whether that is a sensible option?
I'm sure you had reasons to do it this way. But given sufficient time to market, implementing the algorithm in pyre and then tooling/llm assisted conversion to pyrefly would've been preferable.
May be you'd have had some humans in the loop initially. But that tech is getting better and aligned with the direction Meta and the rest of the industry are taking.
Yes, I'm biased :)
Is this how it is now? Not the first time I hear this brainrot idea.
They're saying this on fb.com. How does it not have anything to do with fb?
The feedback section takes you to fb's github.
See also:
https://github.com/microsoft/pyright/blob/main/docs/mypy-com...
https://htmlpreview.github.io/?https://github.com/python/typ...
Fwiw I think performance and features are kind of intertwined here, since Pyright’s extra speed makes it possible to infer more things that are not easy for mypy, especially in an LSP implementation.
Pyright is very impressive in that second link (conformance check), very much a product of Eric Traut & others dedicating a lot of energy to this single problem.
I don't know the differences between the two well enough to know if it was the case here, but in my experience sometimes you need to innovate on a fork, or from scratch in order to create the space/freedom to do so.
Once a project is popular, it's harder to justify and be confident about major changes (aka https://m.xkcd.com/1172/)
Look I get that it's frustrating, but the tool you're whinging about is literally pre-alpha.
Since Meta built this, I have confidence this will be maintained more than others and I will use this and ask for Pyrefly experience in the future.
The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code.
The reason we're stuck on mypy at work is because it's the only type checker that has a plugin for Django that properly manages to type check its crazy runtime generated methods.
I wish more python tooling took the TS approach of "what's in the wild IS the language", as opposed to a "we only typecheck the constructs we think you SHOULD be using".
2. Astral indicated already they plan to just add direct support for Django and other popular languages.
3. As people replied to similar comments on the previous threads (maybe to you?): that's not why ty is fast and why mypy is slow. It's also an easy claim to disprove: run both without plugins and you'll see ty is still 100x+ faster.
That, and duck typing, are one of the biggest things that make Python what it is. If I have to drop all that for type checking and rewrite my code, why would I rewrite it in Python?
Almost no one actually uses eval/exec.
"Here is a nickel, kid, get yourself a better programming language" :-p
https://code.djangoproject.com/ticket/32759
Similar (but lesser) problems exist with pydantic and sqlmodel. They're both fine projects except for:
https://www.reddit.com/r/Python/comments/1i5atpy/fquery_meet...
This is a long winded way of saying type checkers will deal with:
@sqlmodel
@pydantic
@dataclass
class MyModel:
name: str
source: spent several years working on a python type checker
It might not be tied to VS Code but the title clearly says “New […] IDE experience for…” which is why I commented. I had hoped to see something for PyCharm or even a new IDE.