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

11–20 of 150 posts

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

#11

Post by pawelkobojek »

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 forward to have a fast language server for python though, pyright is way too slow for large projects.

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

#12

Post by JimDabell »

drcongo wrote: post #7
jerrygenser wrote: post #4

Earlier quoted context omitted.

Basedpyright is not rust but it's a fork of pyright with added features that are otherwise locked in vscode

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

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

#14

Post by tialaramex »

f311a wrote: post #3
zelphirkalt wrote: post #2

Another one I recently discovered and that has a very active maintainer is "zuban" or zuban-ls. It has replaced jedi-language-server for me, and aims to replace mypy as well.

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.

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

#15

Post by whalesalad »

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 Unix spirit alive: small, composable tools that play nicely together and can be interchanged.

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

#16

Post by veber-alex »

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…

Yeah I have a similar experience with ty.

Looks like none of these new type checkers are ready yet.

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

#17

Post by parhamn »

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?

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

#18

Post by f311a »

veber-alex wrote: post #16
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…

Yeah I have a similar experience with ty. Looks like none of these new type checkers are ready yet.

Ty has autocomplete for imports, but it's hidden behind a toggle right now. They are still working on it. They index all the modules and functions, so you can just type the function name and it will suggest the correct import and insert it.

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

#19

Post by boxed »

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?

Or that x is unused?

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

#20

Post by pawelkobojek »

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?

Exactly - something along the lines of "Statement is unreachable".
Post reply on HN