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

51–60 of 150 posts

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

#51

Post by kstrauser »

giancarlostoro wrote: post #29
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…

A quibble: Python is strongly typed. It’s not un-typed in any reasonable sense of the word. It’s dynamically typed, though: type information is on objects, not on the names referring to them.

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

#52

Post by arccy »

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.

yeah we all heard that story every 3 months with all the previous package managers. until there's adoption by an overwhelming majority of projects, it isn't really settled yet.

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

#53

Post by eqvinox »

Hm, it doesn't seem to be dealing particularly well with imported packages that don't have type annotations. Seeing a bunch of "has no attribute" warnings. Some of the "substitute" annotations also seem to be wrong (e.g. asyncio in CPython has no annotations [in my installed version], but it's pulling some in from somewhere and they're not quite right…) It's also getting confused about lists and tuples in __slots__.

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

#54

Post by rasulkireev »

codethief wrote: post #42
rasulkireev wrote: post #32

This looks interesting. But I decided to go with ty in my projects, for the incremental approach.

How well does ty work these days? Last time I checked it still produced a lot of false positives and false negatives. (Which was very much expected, given its alpha/WIP status.)

Honestly i barely use it, just started to give it a try by adding types where it makes most sense and running with pre-commit. No issues so far. But, again, I'm a very light user.

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

#55

Post by kstrauser »

phailhaus wrote: post #45
flanked-evergl wrote: post #37

Sadly, the question with both this and ty is: Does it support pydantic? If not, then it's not really helpful for many people, and right now AFAIK neither supports pydantic. Pydantic is probably the problem here, but it is what it is.

Python's type system is the problem here, which cannot support even the native dataclass pattern and needs custom plugins written for each type checker.

The type system’s alright. It just gets especially tricky when you’re trying to check code which won’t exist until you run it. For instance, suppose you wanted to load your own module from a database with something like

  foo = eval(result)
It can’t know what you’re going to load until it actually does it.

Things which lean heavily into metaprogramming, typically ORMs or things like Pydantic, fall into that category. I can’t hold that against the type system.

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

#56

Post by Austizzle »

wiz21c wrote: post #40
parhamn wrote: post #17

Earlier quoted context omitted.

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

isn't it perfectly valid to pass None to that function ? It's not like python enforces types at runtime nor at compile time. Right ?

It's not valid from a typing perspective, but python will let you. If you want to disregard types though then none of this matters anyway and you won't get much benefit from these tools

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

#57

Post by kstrauser »

JimDabell wrote: post #12
drcongo wrote: post #7

Earlier quoted context omitted.

It's also horrible for fasle positives unless your project happens to be the exact same setup as the maintainers' - I had to turn off the actual type checking on it. I've since moved wholesale to the Ty alpha and it feels a hell of a lot smarter.

It also inherits the unfortunate attitude of Pyright that it will warn against idiomatic Python (EAFP) in favour of non-idiomatic Python (LBYL): https://github.com/microsoft/pyright/issues/1739 https://docs.python.org/3/glossary.html#term-EAFP https://docs.python.org/3/glossary.html#term-LBYL

Eww, what? I hadn’t seen that before. Yikes, I hope the situation’s improved. I’d be butting into that continually.

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

#58

Post by yesb »

wiz21c wrote: post #40
parhamn wrote: post #17

Earlier quoted context omitted.

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

isn't it perfectly valid to pass None to that function ? It's not like python enforces types at runtime nor at compile time. Right ?

Sure, it's valid python to do that. By that logic you could also pass an int. But the context of this post is that you're using a static type checker.

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

#59

Post by kibwen »

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 is interesting that nobody was writing these tools in C or in C++

This one's easier to explain. People interested in tooling for a specific language probably want to write that tooling in that language (hence pip, poetry, mypy, jedi, etc). Normally that would be the end if it, if Python wasn't 10-100x slower than a natively compiled language. And going from Python to Rust is an order of magnitude easier than going from Python to C or Python to C++, because the compiler is so good at identifying silly mistakes. Rust is just a friendlier language.

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

#60

Post by WesolyKubeczek »

parhamn wrote: post #23
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

The fact that you even didn't mention webpack, once a champion, is especially sad.
Post reply on HN