Pyrefly: Python type checker and language server in Rust • Hacker News Board

Re: Pyrefly: Python type checker and language server in Rust

#111

Post by sirfz » Tue, Oct 14, 2025, 6:30 PM UTC

kinto wrote: post #92

sirfz wrote: post #38

I've decided to to try out Pyrefly, Ty and Zuban for their language server features (type checking disabled where possible) last week and found that Zuban is the fastest (but unfortunately doesn't currently have the option to disable type checking). Ty comes next and Pyrefly was surprisingly slow to load (have to wait a few seconds before I can goto definition for example). They all lack certain features vs basedpyri…

Hey, Pyrefly developer here, thanks for trying us out! We're dedicated to providing a great IDE experience, though it does take some time. Please bother us on github / our discord if you have features you want - bug reports / community asks are our biggest priority. - auto import is implemented in Pyrefly: it uses your pyrefly.toml project structure or falls back to your VSCode workspace (up to the first 2500 files).…

Hi, thanks for the links and for opening the goto declaration issue (that's awesome). I will try to dedicate more time into my setup and provide feedback where possible. Looking forward for all the new updates!

Re: Pyrefly: Python type checker and language server in Rust

#112

Post by screye » Tue, Oct 14, 2025, 6:31 PM UTC

alfalfasprout wrote: post #91

screye wrote: post #66

Earlier quoted context omitted.

If ruff & uv have proved anything, it's that a tool that's effortless, a net-positive and fast will get adopted. New typecheckers don't need to be perfect. They need to be good enough, easy to integrate and have low false positives. Sure, they will improve with time, but if feels like a pain then no one will pick it up. Python users are famously averse to tools that slow down their dev cycles, even if it means better…

> New typecheckers don't need to be perfect. They need to be good enough, easy to integrate and have low false positives. Sure, they will improve with time, but if feels like a pain then no one will pick it up. Python users are famously averse to tools that slow down their dev cycles, even if it means better long term stability I really don't agree. Sure, they don't need to be perfect but also keep in mind many codeb…

Think of it this way. There are 2 groups. Group 1 has has avoided typecheckers because they're a PITA and group 2 has configured mypy/pyright despite the devx pain. Group 1 is a lot bigger than group 2. Group 2 is more lucrative per unit than group 1.

With enough time, ty and pyrefly will approach perfectness. If they're easy enough to use today, group 1 should be able to adopt them without any extra pain. (some typechecker is better than no typechecker). This gives them momentum. In couple of years, ty/pyrefly may finally be better than mypy/pyright. Then, Group 2 can start their ports.

This way, no one misses out. Group 2 still gets their perfect typechecker, just not immediately. But in that time, Group 1 is getting familiar with using typecheckers and their sheer size helps build institutional momentum towards typecheckers as an essential piece of any python dev flow.

If A. 'certain class of python problems are permanently solved by typecheckers' and B. 'every python user has some typechecker' become true, then that opens a lot of doors. Today, B is a harder problem than A. I'm guessing that compiled/JIT python will be the next frontier once python typing is solved. Wide typechecker adoption is a blocking requirement for that door to be opened.

Re: Pyrefly: Python type checker and language server in Rust

#113

Post by nprateem » Tue, Oct 14, 2025, 6:31 PM UTC

natdempk wrote: post #98

Anyone here know what the ideal/best setup is for typechecking + LSPing Django these days? I've been leaning on pyright + django-stubs, but wondering if I'm missing something better with fewer gaps and pain points.

Just started trying ty with django-types. I got the models typed in a day or so. Still wading through the other 200+ errors in my codebase. But it's fast at least.

Re: Pyrefly: Python type checker and language server in Rust

#114

Post by IshKebab » Tue, Oct 14, 2025, 6:35 PM UTC

whalesalad wrote: post #15

Python is starting to feel a bit like JavaScript circa 2014. Remember grunt, gulp, webpack, coffeescript, babel? Now we've got pyright, mypy, pyrefly, black, ruff, ty, flake8, poetry, uv... I used to find this kind of tooling explosion exhausting (and back then with JS it truly was), but generally speaking it's a good sign that the community is hungry to push things forward. Choice is good, as long as we keep the Uni…

It's not really that bad. Unless you want to be adventurous you need these tools:

* uv: project management, formatting

* Pyright: type checking

* Pylint: linting (this is probably optional though I would strongly recommend it). Ruff is an option but I don't think it is quite as comprehensive yet.

There are alternatives for those tools but they are pretty clearly the best options at the moment. There's nothing in uv's league, and the only alternatives in Pyright's league is BasedPyright. Hopefully Ty and Pyrefly will be good options in future but I don't think they're ready for production use just yet.

Re: Pyrefly: Python type checker and language server in Rust

#115

Post by IshKebab » Tue, Oct 14, 2025, 6:37 PM UTC

insane_dreamer wrote: post #28

I've tried pyrefly, ty, pyright, and basedpyright, with a large complex code base written using PyCharm, and _none_ of them do as good a job as PyCharm, particularly in discovering more complex type inheritances. It's a pity because in other respects Zed (which relies on these) is a worthy competitor to PyCharm (and much faster!) -- but the endless squiggly lines because pyrefly can't figure out the type, is annoying…

Are you talking about with code that has proper type annotations? As I recall PyCharm is about the best you can get if you are working with code that has no type annotations but ... you shouldn't be doing that in 2025! With type annotations I've found Pyright to be 100% rock solid.

Re: Pyrefly: Python type checker and language server in Rust

#116

Post by IshKebab » Tue, Oct 14, 2025, 6:38 PM UTC

f311a wrote: post #86

wiseowise wrote: post #72

Earlier quoted context omitted.

Wasn’t pyright made specifically for VSCode? That would explain TS.

Yes, but why they did not write it in a compiled language? Pyright is pretty slow in large code bases and takes a lot of RAM. Javascript can be faster than python in some cases, but Python is so easily extendable with C,C++, Cython, Rust. They could use Python with one of the compiled language.

Because they wanted it to be usable on the web, and I guess WASM wasn't where it is right now when they started.

Re: Pyrefly: Python type checker and language server in Rust

#117

Post by IshKebab » Tue, Oct 14, 2025, 6:40 PM UTC

JimDabell wrote: post #78

maleldil wrote: post #70

Earlier quoted context omitted.

Sometimes dynamic Python idioms are incompatible with typed Python. I personally think that's fine, since I consider static typing a significant improvement overall.

This isn’t. They actually fixed that bug. Then they changed their minds and backed the fix back out again because they don’t think you should write Python that way : > I think EAFP is a very unfortunate and ill-advised practice. They want you to not write the idiomatic Python: try: foo = bar["baz"]["qux"] ... except KeyError: ... …and instead write the non-idiomatic version: if "baz" in bar and "qux" in bar["baz"]: f…

Well I agree with them. The second code is clearly better. Exceptions should be used for error handling and if those keys are actually optional then you should explicitly check if they exist (or use something like `bar.get("baz")`).

Re: Pyrefly: Python type checker and language server in Rust

#118

Post by underdeserver » Tue, Oct 14, 2025, 6:47 PM UTC

scosman wrote: post #50

emddudley wrote: post #10

Earlier quoted context omitted.

Pyrefly vs. ty: Comparing Python’s Two New Rust-Based Type Checkers (2025-05-27) https://blog.edward-li.com/tech/comparing-pyrefly-vs-ty/ HN discussion of above: https://news.ycombinator.com/item?id=44107655 How Well Do New Python Type Checkers Conform? A Deep Dive into Ty, Pyrefly, and Zuban (2025-08-29) https://sinon.github.io/future-python-type-checkers/

amazing reply. Thanks!

A note - the second link talks mostly about conformance with a standard suite of tests, only briefly touching on real-world use.

I would very much like to understand how good Zuban is today compared to the competition.

Re: Pyrefly: Python type checker and language server in Rust

#119

Post by ObscureScience » Tue, Oct 14, 2025, 6:48 PM UTC

tremon wrote: post #93

atoav wrote: post #80

Earlier quoted context omitted.

If car crashes still kill people, why wear safety belts?

I don't think that's an accurate metaphor. Seatbelts are expressly a runtime solution to car crashes, whereas Python's type checking is a) only done during development (not even during build), and b) completely reliant on third-party tools. If you're looking for a car analogy, I would suggest comparing Python type checking to installing speed cameras on the factory floor.

The analogy would be mandatory inspections of certain components or manufacturing processes to see that rules and specs are followed while assembling.

Re: Pyrefly: Python type checker and language server in Rust

#120

Post by cadamsdotcom » Tue, Oct 14, 2025, 7:07 PM UTC

Been using pyrefly since July on a big python build.

It has some things it can’t pick up on - no return after a catch block when all code paths are covered for example - but it’s speedy and the error messages are good enough for Claude to understand and ignore or resolve.

Recommended!