Pyrefly - A faster Python type checker written in Rust
pyrefly.org
pyrefly.org
Pyrefly is a work in progress, but you can install it from pypi and/or try our alpha VSCode extension if you are interested. You may still get false positive errors on your project as we are still burning down bugs and some features. We would love comments, bugs, or requests on our GitHub as you try it out.
Lastly, one of our team members is giving a talk at PyCon about the design if folks are interested: https://us.pycon.org/2025/schedule/presentation/118/. We didn’t expect much attention before then, so thanks for taking a look!
Refer to the crates starting with red_knot in this directory to follow its development: https://github.com/astral-sh/ruff/tree/main/crates
The latest commit was only an hour ago.
They use the code internally but fail at making sure it has use externally. This is doubly the case for anything infrastructure
Buck2: Was released. Never could be built correctly without the latest nightly of Rust and even then it was fragile outside of Meta's build architecture
Sapling: Has a whole bunch of excitement and backing when it was announced. Has been essentially dead 3 mos after release.
I used to work for Meta infra. I know the MO. Have a hard time trusting.
Astral use-case is external and has a better chance of actually being supported.
Have not tried building Buck2 (no personal use for it), but its also actively developed: https://github.com/facebook/buck2/commits/main/
Both are EXTREMELY active but only for the needs of Meta and not for the community.
Adoption outside of Meta is nearly non-existent because of this.
Look at something like Jujitsu. instead of Sapling and you can see a lot more community support, a lot more focus on features that are needed for everyone (still no LFS support, but it wasn't because Google didn't need it).
I guess I don't consider a larger number of commits as actively supporting the community. The community use is second place and the open source is just a one time boost to recruiting PR.
We know we can't just ask for trust upfront. Instead, we want to earn it by showing up consistently and following through on our commitments. So, take us for a spin and see how we do over time. We're excited to prove ourselves!
But I’ve had the same issue with too many warnings, mypy is better at understanding Python but even slower.
As for version bumping, maybe it’s just a me thing, but I hard fix a version and only update occasionally. Sure each update brings new warnings, but most of them are valid and if you only do it a couple times a year… not that big a deal.
The only thing I found it ‘missing’ was an indentation check (it’s in preview, I don’t turn on preview rules), but I realized it doesn’t matter because we also have a formatter running on everything.
The dependency on node makes it a PITA to set up in non-vs code environments as well.
I agree that most of the functionality on top of the type checker/engine is better in pycharm though. But a correct implementation is more important
Idiomatic Python favours EAFP (Easier to Ask Forgiveness than Permission) over LBYL (Look Before You Leap), so you might write something like this when using TypedDicts:
try:
foo = bar["baz"]["qux"]
...
except KeyError:
...
if "baz" in bar and "qux" in bar["baz"]:
foo = bar["baz"]["qux"]
...
else:
...
— https://github.com/microsoft/pyright/issues/1739
Now if this were a linter then I would understand. But a type checker should not be opinionated to the point of pushing people not to use idiomatic Python.
if bar.get("baz", {}).get("qux") is not None:
...* Was overwhelmingly slower than mypy
* Had a few hundred more false positives. I gather from reading their philosophy afterward that this was on purpose. Rigid dogma > doing the right thing in the circumstance in their opinion.
* Did not find any actual bugs, whereas mypy identified 3 errors that lead to fixing real issues AND had fewer false positives, due to its better understanding of python code.
* Comically overweight with its typescript dependency.
My first impression of it was of a very low quality, over engineered project prioritizing noise over signal. Looking forward to trying out the astral typechecker as well.
In particular for me it would be great to have a better typechecker than Pyright available for Zed (basically why the editor is a nonstarter right now).
That's a high bar!
I'm wondering though, why do existing tools like Mypy and Pyright not scale for Meta? Is Pyre(fly) being used extensively at Meta? In general what sort of issues did Meta run into?
> INFO 5,240 errors shown, 65,932 errors ignored
Not a single Python type checker had ever worked for me so far.
I don't know. Some packages just don't work with type checkers, e.g. Django.
edit: most errors weren't actually import-error, I just misunderstood --search-path
Working with these things makes me often think that people who want to write high quality software should just use a better language. But, well, real world is real.
This
If fairness if you set up uv and Ruff and Pyright it's kind of ok. Still have to deal with the general noobness of the ecosystem and the horrific performance, but I've seen worse.
We also allow you the ability to suppress whole classes of errors if you want to ignore specific error types and avoid inline ignores: https://pyrefly.org/en/docs/configuration/ A word of caution: this will ignore future errors of this type as well.
First, make sure your project is properly configured and then follow the instructions. `--suppress-errors` will add ignores inline allowing the project to check cleanly. We have thought about a feature that allows you to keep suppressions in a separate file, but we have not put it on the roadmap yet. If this is something important for your workflow, we would like to learn more - please add a feature request on GitHub.