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

91–100 of 150 posts

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

#91

Post by alfalfasprout »

screye wrote: post #66
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…

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 codebases have already standardized on something like (based)pyright or mypy. So there's a migration cost. If your analysis has a lot of false positives or misses a lot of what those type checkers miss then there's little incentive to migrate. Sure, ty and pyrefly are much faster, but at the end of the day speed is only one consideration for a type checker.

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

#92

Post by kinto »

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). we're happy to fix it for your situation if you want to provide a reproduction

- signature/doc when selecting autocomplete options is a known bug [here](https://github.com/facebook/pyrefly/issues/1090)

- go to declaration: I've created an issue for that [here](https://github.com/facebook/pyrefly/issues/1291), it should be quick.

- speed: by far the biggest issue. your problem is likely related to [this](https://github.com/facebook/pyrefly/issues/360) but we need more information to speed it up. we're happy to work with you to to improve this if you're willing to provide a project structure

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

#93

Post by tremon »

atoav wrote: post #80
phplovesong wrote: post #67

Earlier quoted context omitted.

If typechecking is tongue on cheek, why even bother?

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.

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

#94

Post by fragmede »

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…

No, I'm pretty sure they need to be perfect. If the tool's telling me bad information about types, first I'm going to lose a stupid amount of time debugging to that wrong info, and then swear off the tool forever after I realize it was the tool that was wrong.

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

#95

Post by Too »

Anyone struggling with slow mypy should really update to latest version. This years releases has focused on performance and it has payed off. Add the boost from latest Python versions to that and you can see 50% type checking improvements. Still far from a rust based tool, always something, all without changing your tool chain.

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

#96

Post by kinto »

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…

Hey, Pyrefly developer here, thanks for trying us out! Thanks for bearing with us with these issues you're experiencing while we're still in alpha.

We're planning on adding unreachable code diagnostics soon (github issue [here](https://github.com/facebook/pyrefly/issues/1292)). These come for free with Pyright so we don't want to regress features.

I'm happy to help diagnose/fix your autocomplete issue: it should work on modules. If you want to provide details here, on [discord](https://discord.gg/Cf7mFQtW7W), or as a Github issue (github/discord preferred) we'll fix it for you + anyone else with the problem.

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

#97

Post by ehsanu1 »

jswny wrote: post #47
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…

At least for Ty, not sure about the others, it is explicitly for type checking, exposed as an LSP. It’s not trying to compete with full LSP implementations. Most modern editors let you combine multiple LSPs, you shouldn’t think of them as using only one at a time

Do you assign different responsibilities to different LSP servers when there multiple I suppose?

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

#100

Post by mixmastamyk »

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…

The billion dollar mistake.
Post reply on HN