6 ms·
Pyrefly - A faster Python type checker written in Rust
- deleted 1y ago[deleted]
- koakuma-chan 1y ago> 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.
- kstrauser 1y agoI don't see the link between that output and your conclusion. Are those results wrong?
- koakuma-chan 1y ago> Are those results wrong? I don't know. Some packages just don't work with type checkers, e.g. Django.
- masklinn 1y agoDjango has a community stubs project, are you using it?
- etimberg 1y agothe stubs can only do so much. There's so much magic and inferred properties that a type checker will never be able to fill in alone
- aitchnyu 1y agoDoes django-stubs work with other type checkers than Pyright?
- masklinn 1y agoStubs are a standard python feature (PEP 561) so I'd expect them to work with any type checker which supports stubs, which should be all of them (as much of the ecosystem is typed via stubs).
- johnisgood 1y agoIs it not that he used the "--suppress-errors" flag yet it did not ignore the errors?
- kstrauser 1y agoIt's hard to tell. Other similar options in other commands can mean things like "exit with status 0 even if errors are detected". Without installing pyrefly, I'm not sure what that flag's supposed to do. It's not documented on their site.
- koakuma-chan 1y agoIt adds a comment to suppress the error above each line in your codebase that causes an error, but it reports the errors before doing that, so you can only see the result after you re-run `pyrefly check`.
- kstrauser 1y agoOh! That's nifty. It leaves you with a baseline so you can stop making new mistakes, and gives you something to grep for when you want to fix existing ones.
- ipsum2 1y agoIt's literally working? What did you expect?
- koakuma-chan 1y agoMaybe it's working but it's not useful.
- masklinn 1y agoWhat would you expect "useful" to be if your codebase is basically incompatible with type checking?
- koakuma-chan 1y agoI expected that I would be able to run the check command and it would just work. Upon reading the docs, this tool recommends incremental adoption, and after using `--suppress-errors`, `# pyrefly: ignore` is all over my codebase.
- Yossarrian22 1y ago…how else would it work?
- nerdponx 1y agoThat's incremental adoption for adding type hints, not for adopting this particular tool in an already-type-hinted codebase.
- krick 1y agoI know I shouldn't get into this thread, but I'm extremely curious: what did you expect should have happened? I mean, literally, what do you mean by "just work", what work did you expect a type checker to perform if not to show you errors?
- koakuma-chan 1y ago
- ForHackernews 1y agoFix your types.
- IshKebab 1y agoDo you... have type annotations? I think you might be missing the point.
- jon-wood 1y agoI think the point here is that for something like Python the default behaviour should be an assumed return type of `Any` rather than throwing an error. Maybe that is the case and the GP had configured it otherwise.
- IshKebab 1y agoNo it shouldn't because then you can easily miss places where you should have added a type annotation, and also your lazy colleagues won't bother adding them at all.
- darthrupert 1y agoThe worst of both worlds is colleagues who insert type annotations but they're wrong. And there's no CI pipe to verify the types before check-in. 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.
- koakuma-chan 1y ago> just use a better language This
- IshKebab 1y agoYeah unfortunately Python is crazy popular so a lot of the time you don't get a choice. 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.
- team_pyrefly 1y agoThanks 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/ 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/ 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.
- darthrupert 1y agoDon't blame the tool for your shoddy work. Either accept your mediocre quality or do something to fix it.
- femtozer 1y agoThe team behind ruff/uv is working on a similar tool: https://x.com/charliermarsh/status/1884651482009477368 https://x.com/charliermarsh/status/1884651482009477368
- joshdavham 1y agoHave there been any updates on when they think it’ll be released?
- singhrac 1y agoAt least the alpha milestone is May 12, but I don't think they've publically committed to anything. 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).
- Y_Y 1y agoAn editor is a nonstarter because it doesn't doesn't integrate the right implementation of some particular optional feature for some particular language? That's a high bar!
- drcongo 1y agoI have some sympathies with the parent post as Zed is my daily driver and I mostly write Python. Pyright is horrible to work with, tons of false positives. Parent poster - you might find this useful: https://github.com/zed-industries/zed/discussions/24801 https://github.com/zed-industries/zed/discussions/24801
- hopfenspergerj 1y agoNo it is not horrible to work with. Even the “standard” settings are quite lax.
- 1y ago
- emptysea 1y agoA rewrite of https://github.com/facebook/pyre-check https://github.com/facebook/pyre-check in rust?
- codethief 1y agoMy thought exactly! Maybe for performance reasons? (Though I wouldn't expect OCaml to perform that badly, either…)
- team_pyrefly 1y agoYes, this is a ground up rewrite: https://pyrefly.org/en/docs/pyrefly-faq/#what-is-the-relationship-to-pyre https://pyrefly.org/en/docs/pyrefly-faq/#what-is-the-relatio...
- nine_k 1y agoOn 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.
- alexmolas 1y agoThe 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.
- maxloh 1y agoIt 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 https://github.com/astral-sh/ruff/tree/main/crates The latest commit was only an hour ago.
- nemith 1y agoAlso 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.
- wocram 1y agoIs this standard promotion driven development? Or do the people who are trying to open source these products end up being blocked?
- nemith 1y agoWhen I was there (which was a while ago) almost every decision was based around PSC (Performance Summary Cycle) and it's easy to justify a good rating for a large project being open sourced. Less so to make sure it's well supported for the use cases of the community.
- WD-42 1y agoCannot wait to get rid of pyright, but I’ll be holding out for Astrals type checker.
- nikisweeting 1y agoI've loved pyright so far, what do you dislike about it?
- ndr 1y agoIt's slow as hell. And every version bump comes with a bunch of new warnings/errors by default that is quite disruptive if you want to keep it quiet. But mostly that it is annoyingly slow.
- emptysea 1y agoMight be worth checking out https://github.com/DetachHead/basedpyright https://github.com/DetachHead/basedpyright But I’ve had the same issue with too many warnings, mypy is better at understanding Python but even slower.
- addoo 1y agoI guess it’s all relative. One of my code bases still has pylint running with only a couple custom lint rules, that one is slow as hell. 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.
- team_pyrefly 1y agoHi 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/ 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/ https://us.pycon.org/2025/schedule/presentation/118/. We didn’t expect much attention before then, so thanks for taking a look!
- odie5533 1y agoThis 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?
- team_pyrefly 1y agoWe go into it a bit more here: https://pyrefly.org/en/docs/pyrefly-faq/ 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!