Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pyrefly: Python type checker and language server in Rust

pyrefly.org

Post reply on HN
Print view View original

21–30 of 150 posts

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

#21

Post by robertlagrant »

parhamn wrote: post #17
pawelkobojek wrote: post #11

I love the speed advantage of pyrefly over (based)pyright but so far it doesn't seem to highlight as much as pyright does, for example it doesn't catch unreachable code like this: def fn(x: str): if x is None: x = "123" # pyright flags that as unreachable code, pyrefly does not Autocomplete for modules also doesn't work for me yet: import os os. # I'll get `ABC, `Any`, `AnyStr`, `AnyStr_co`, `BinaryIO`, ... Looking f…

Whats the expected error in the example you gave? That x can't be none because it was received as a str?

Yes, exactly. x would have to be str | None to be reachable.

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

#22

Post by strangescript »

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…

"grunt, gulp, webpack, coffeescript, babel" --- except no one uses these anymore and they are dead outside of legacy software.

The problem with the python tooling is no one can get it right. There aren't clear winners for a lot of the tooling.

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

#23

Post by parhamn »

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…

Interestingly besides typescript, javascript in 2025 is still super fragmeneted but by a bunch of well-polished tools that all do approximately the same thing. esbuild/vite(rollup)/trubopack(swc), prettier/biome/oxc, npm/bun/pnpm/yarn, bun/node/deno/worker-runtimes

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

#25

Post by vovavili »

arccy wrote: post #8
f311a wrote: post #3

Earlier quoted context omitted.

Yeah, there are now 3 competitors and they all written in Rust: - zuban - ty (from ruff team) - pyrefly One year ago, we had none of them, only slow options.

it'll be like python package managers and js web frameworks.... a new one every quarter

uv works so well for the vast majority of scenarios that I don't really see a demand for further innovation in the Python package manager domain.

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

#27

Post by f311a »

tialaramex wrote: post #14
f311a wrote: post #3

Earlier quoted context omitted.

Yeah, there are now 3 competitors and they all written in Rust: - zuban - ty (from ruff team) - pyrefly One year ago, we had none of them, only slow options.

Speed is one of those "Quantity has a quality all its own" things. We use very fast tools in a qualitatively different way, even though all that changed was how long it takes in seconds. It is interesting that nobody was writing these tools in C or in C++. There are obvious ergonomic reasons, but perhaps also it matters that Rust cares a lot more about types than either of those languages.

It's just very hard to write such systems in C/C++. Even all these Rust versions are segfaulting and panicking quite a lot. So many corner and edge cases that can be found in Python code, and the memory handling is also hard.

The author of Zuban started writing it back in 2020 or 2021, so it took him more than 4 years to complete it. And he is the author of Jedi, so he had prior experience already.

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

#28

Post by insane_dreamer »

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 (and turning off the warnings is unhelpful). Hopefully one of these will get up to PyCharm's level (my money would be on ty as Astral is kicking a* these days).

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

#29

Post by giancarlostoro »

pawelkobojek wrote: post #11

I love the speed advantage of pyrefly over (based)pyright but so far it doesn't seem to highlight as much as pyright does, for example it doesn't catch unreachable code like this: def fn(x: str): if x is None: x = "123" # pyright flags that as unreachable code, pyrefly does not Autocomplete for modules also doesn't work for me yet: import os os. # I'll get `ABC, `Any`, `AnyStr`, `AnyStr_co`, `BinaryIO`, ... Looking f…

It's funny because in other typed languages a string can be null because of string being a reference type as opposed to a value type. I think Python type hints make more sense than C# does in this respect, which gives me a chuckle (two of my favorite languages and the untyped one makes more sense with types). That said, not sure if you already have but I would add a github issue / ticket reporting your issue to raise awareness to the devs.

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

#30

Post by insane_dreamer »

vovavili wrote: post #25
arccy wrote: post #8

Earlier quoted context omitted.

it'll be like python package managers and js web frameworks.... a new one every quarter

uv works so well for the vast majority of scenarios that I don't really see a demand for further innovation in the Python package manager domain.

it still needs to add handling for binaries (the one thing conda can do that uv can't)
Post reply on HN