Hi Hackernews, I’m on the team working on Pyrefly at Meta. We address a lot of the comments in our FAQ: https://pyrefly.org/en/docs/pyrefly-faq/. I will try to address some questions directly too!
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!
On one hand, "launching Spring 2025". On the other hand, 47% complete, with a ton of basic stuff not yet ready. I wonder how fast they plan to move, given that only 32 days remain of the spring.
The astral team (behind uv and ruff) is already working on a type checker in Rust, and given the quality of their existing tools, I'm inclined to wait and see what they release. Pyrefly looks interesting, but from the repo it seems pretty early-stage and not intended for external use yet.
Also Facebook has a history of releasing the source code for something. Making a huge splash and then essentially doing nothing after 3 months (aka after someone gets their review).
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.
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!
It has warnings that steer you away from idiomatic Python towards less idiomatic Python.
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:
Pyright warns you about this and pushes you to write this:
if "baz" in bar and "qux" in bar["baz"]:
foo = bar["baz"]["qux"]
...
else:
...
They identified this as a bug and fixed it, then changed course and decided to reinstate the behaviour. So if you want to write idiomatic Python, you need to disable typechecking TypedDicts.
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.
When I last compared it to mypy a few months ago adding typechecking to an old project that had types but I had for some reason never actually run a typechecker on it:
* 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.
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?
We go into it a bit more here: https://pyrefly.org/en/docs/pyrefly-faq/ The short answer is that the scale of the Python projects we work on is huge. Pyre is the only checker that can scale for our needs today. To bring modern features like type inference and better IDE integration, a full rewrite needed to happen. We are not done just yet, but have been using our massive codebases to test the performance and flexibility of the checker. Thanks for the question!
Thanks for giving this a try! We go over how to use the upgrade tooling (`--suppress-errors`) in the guide here: https://pyrefly.org/en/docs/installation/. This is intended to make upgrading from different versions of type checkers easier. It’s something we use internally and wanted to share with the community along with the checker itself.
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.
Hi Hackernews, I’m on the team working on Pyrefly at Meta. We address a lot of the comments in our FAQ: https://pyrefly.org/en/docs/pyrefly-faq/. I will try to address some questions directly too!
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!
A rewrite of https://github.com/facebook/pyre-check in rust?
Yes, this is a ground up rewrite: https://pyrefly.org/en/docs/pyrefly-faq/#what-is-the-relatio...
My thought exactly! Maybe for performance reasons? (Though I wouldn't expect OCaml to perform that badly, either…)
On one hand, "launching Spring 2025". On the other hand, 47% complete, with a ton of basic stuff not yet ready. I wonder how fast they plan to move, given that only 32 days remain of the spring.
Not in southern hemisphere.
It's not "47% complete", it's just that (now) 52% of the issues in a milestone are complete.
We’re 53 days away from summer though.
The astral team (behind uv and ruff) is already working on a type checker in Rust, and given the quality of their existing tools, I'm inclined to wait and see what they release. Pyrefly looks interesting, but from the repo it seems pretty early-stage and not intended for external use yet.
Also Facebook has a history of releasing the source code for something. Making a huge splash and then essentially doing nothing after 3 months (aka after someone gets their review).
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.
We totally get why you might be skeptical and even address this in our FAQ: https://pyrefly.org/en/docs/pyrefly-faq/#how-do-i-know-this-...
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!
Sapling is actively developed, not "dead after 3 months": https://github.com/facebook/sapling/commits/main/
Have not tried building Buck2 (no personal use for it), but its also actively developed: https://github.com/facebook/buck2/commits/main/
Is this standard promotion driven development? Or do the people who are trying to open source these products end up being blocked?
It is codenamed "Red Knot".
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.
astral team has live web demo they use internally of redknot on https://playknot.ruff.rs
At first I thought this was the release from Astral for their type checker. Same boat, sitting tight, holding champagne ready for that day too.
Cannot wait to get rid of pyright, but I’ll be holding out for Astrals type checker.
I've loved pyright so far, what do you dislike about it?
It has warnings that steer you away from idiomatic Python towards less idiomatic Python.
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:
Pyright warns you about this and pushes you to write this: They identified this as a bug and fixed it, then changed course and decided to reinstate the behaviour. So if you want to write idiomatic Python, you need to disable typechecking TypedDicts.— 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.
When I last compared it to mypy a few months ago adding typechecking to an old project that had types but I had for some reason never actually run a typechecker on it:
* 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.
The team behind ruff/uv is working on a similar tool:
https://x.com/charliermarsh/status/1884651482009477368
Have there been any updates on when they think it’ll be released?
This is awesome! Thank you for sharing it!
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?
We go into it a bit more here: https://pyrefly.org/en/docs/pyrefly-faq/ The short answer is that the scale of the Python projects we work on is huge. Pyre is the only checker that can scale for our needs today. To bring modern features like type inference and better IDE integration, a full rewrite needed to happen. We are not done just yet, but have been using our massive codebases to test the performance and flexibility of the checker. Thanks for the question!
> pyrefly check --suppress-errors
> 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 see the link between that output and your conclusion. Are those results wrong?
Thanks for giving this a try! We go over how to use the upgrade tooling (`--suppress-errors`) in the guide here: https://pyrefly.org/en/docs/installation/. This is intended to make upgrading from different versions of type checkers easier. It’s something we use internally and wanted to share with the community along with the checker itself.
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.
It's literally working? What did you expect?
Fix your types.
Don't blame the tool for your shoddy work. Either accept your mediocre quality or do something to fix it.
Do you... have type annotations? I think you might be missing the point.