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

101–110 of 150 posts

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

#101

Post by estebank »

tialaramex wrote: post #35
f311a wrote: post #27

Earlier quoted context omitted.

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.

I get why they'd panic, but why have enough segfaults that you noticed? So, I went and read the code. Zuban seems to have a bunch of scary "I'm not sure if this is correct" unsafe blocks, which to me would be a red flag. I mean, it's better that there's a comment expressing the doubt, but my experience is that if you're not sure whether it's correct, it's probably not correct.

While acknowledging the risk of causing a pile-on (which I don't want!), would it be possible to have a link to them or a description of what the unsafe blocks accomplish? I'm intrigued if they are for performance or API ergonomics, if they are due to limitations of the borrow checker, the stdlib or crate dependencies.

For anyone reaching for unsafe, there are in many cases either an existing API (split_at_mut comes to mind). For others, using zero-copy or bytemuck instead of unsafe is a good idea too.

None of that is to say "never write unsafe", unsafe existing is pretty much one of the reasons for Rust to be :)

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

#102

Post by notatallshaw »

eqvinox wrote: post #90
notatallshaw wrote: post #81

Earlier quoted context omitted.

I assume in your example if you update the foo declaration to the following it solves the complaint: foo: list[str] = [] If so this a type checking design choice: * What can I infer from an empty collection declaration? * What do I allow further down the code to update inferences further up the code? I don't know Pyrefly's philosophy here, but I assume it's guided by opinionated coding guidelines inside Meta, not wha…

Yes, annotating the type explicitly fixes it; but tbh I'd consider that type annotation "unnecessary/distracting code litter". As far as their philosophy goes, it's an open issue they're working on, so their philosophy seems to agree this particular pattern should work :)

I agree, but as a type checker it is a subjective choice, whether to be explicit and not make assumptions or whether to infer from certain certain patterns as probably correct and not be noisy to the user. Very glad to see they plan to fix this.

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

#103

Post by charliermarsh »

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

We actually do want ty to be a first-class LSP (i.e., a complete alternative to Pylance and others), and it already supports nearly all of the features you'd expect. I use it as my primary LSP today in lieu of Pylance!

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

#104

Post by mixmastamyk »

pjmlp wrote: post #85
parhamn wrote: post #23

Earlier quoted context omitted.

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

For me it is easy, Spring/Quarkus/ASP.NET, if it has to be a JavaScript framework, Next.js the way Vercel intended. Anything whatever the FE team feels like using, and the less I know about it, the better.

Next.js has been called infuriating here recently: https://news.ycombinator.com/item?id=45099922

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

#105

Post by pjmlp »

mixmastamyk wrote: post #104
pjmlp wrote: post #85

Earlier quoted context omitted.

For me it is easy, Spring/Quarkus/ASP.NET, if it has to be a JavaScript framework, Next.js the way Vercel intended. Anything whatever the FE team feels like using, and the less I know about it, the better.

Next.js has been called infuriating here recently: https://news.ycombinator.com/item?id=45099922

I know, search for my nickname and you'll get my point of view across several comments.

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

#106

Post by mixmastamyk »

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.

Why would they need to support pydantic when it uses standard annotations? I tried it with ty yesterday and it flagged issues as expected.

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

#107

Post by nickpsecurity »

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…

Also, in the past, many tools were dumped by users for too many false positives. Tools like Astree and RV-Match got adoption by having no or low false positives.

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

#108

Post by kinto »

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.

(Pyrefly dev here)

We've seen a lot of people have success with the mypy plugin + django-stubs.

Full out-of-the-box support is being actively worked on in Pyrefly: we will have specialized django enum support in the next release and we expect real experimental support by the end of the year. At that time we'll likely post a blog post to announce it [here](https://pyrefly.org/blog/).

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

#109

Post by pawelkobojek »

kinto wrote: post #96
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 wo…

I absolutely understand this is still alpha so I kind of assumed these are expected. Frankly, that's why I haven't submitted an issue -- I assumed it's going to be fixed at some point. I'll go ahead and make an issue on GitHub, thanks.

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

#110

Post by sirfz »

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

I understand your confusion because at first look it seems like it's just a type checker (same issue with pyrefly and zuban) hence my comment about bringing forward the fact it's a fully featured lsp
Post reply on HN