Pyrefly: Python type checker and language server in Rust

https://pyrefly.org/?featured_on=talkpython

by brianzelip • 9 months ago

203 144 9 months ago

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.

f311a6• 9 months ago

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.

jerrygenser• 9 months ago

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

arccy2• 9 months ago

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

tialaramex3• 9 months ago

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.

scosman2• 9 months ago

Anyone know how this compares to 'ty': a new typechecker from Astral (uv/ruff team), also written in Rust and super fast. I had been waiting on it to reach beta, but would love to move to something faster than pyright sooner if possible.

emddudley• 9 months ago

Pyrefly vs. ty: Comparing Python’s Two New Rust-Based Type Checkers (2025-05-27) https://blog.edward-li.com/tech/comparing-pyrefly-vs-ty/

HN discussion of above: https://news.ycombinator.com/item?id=44107655

How Well Do New Python Type Checkers Conform? A Deep Dive into Ty, Pyrefly, and Zuban (2025-08-29) https://sinon.github.io/future-python-type-checkers/

scosman2• 9 months ago

amazing reply. Thanks!

pawelkobojek3• 9 months ago

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.

veber-alex• 9 months ago

Yeah I have a similar experience with ty.

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

f311a6• 9 months ago

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.

parhamn2• 9 months ago

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

boxed• 9 months ago

Or that x is unused?

pawelkobojek3• 9 months ago

Exactly - something along the lines of "Statement is unreachable".

robertlagrant• 9 months ago

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

wiz21c• 9 months ago

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 ?

giancarlostoro2• 9 months ago

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.

_flux• 9 months ago

In some other typed languages, that is. E.g. in C++, OCaml, Haskell, F#, Kotlin, and Rust (a non-exhaustive list) you can have non-nullable strings, and other objects.

Scarblac• 9 months ago

All Python types are reference types. The reference to None isn't included in the str type.

There's no way to get an actual null reference, afaik. Variables always have some value, possibly None.

(not sure what happens if you set a reference to null from C - a crash, probably?)

kstrauser3• 9 months ago

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.

seabrookmx• 9 months ago

If you use the nullable types compiler option in C# (which defaults to enabled for new projects) then you need to declare you string as string? for it to be nullable :)

mixmastamyk4• 9 months ago

The billion dollar mistake.

kinto3• 9 months ago

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.

pawelkobojek3• 9 months ago

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.

whalesalad• 9 months ago

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.

strangescript• 9 months ago

"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.

jon-wood2• 9 months ago

I think that's the point. Every now and then a language will have a small explosion of new tooling, and all you can really do is wait for it to blow over and see what tools people adopted afterwards, it feels like Python is going through a period like that at the moment.

parhamn2• 9 months ago

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

WesolyKubeczek• 9 months ago

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

koakuma-chan3• 9 months ago

It's just people refusing to use new tools. Prettier is so much slower than any Rust formatter, it's painful. `yarn install` takes forever. Why not switch to Bun? It's 5 minutes.

pjmlp6• 9 months ago

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.

pjmlp6• 9 months ago

Pity that is all looking like Rewrite in Rust looking for solution, instead of actually improving JIT tooling capabilities.

There is a reason us old timers mostly wait on the sidelines until the dust settles.

We have seen this movie already too many times.

notatallshaw5• 9 months ago

A lot of the tools you list here are composable, mypy checks type hints, black formats code, because of the purpose and design ethos of those two tools they would never think to merge.

So which is it that you want, to just reach for one tool or have tools that have specific design goals and then have to reach for many tools in a full workflow?

FWIW Astral's long term goal appears to be to just reach for one tool, hence why you can now do "uv format".

lenkite• 9 months ago

"There can be only one" - just need to wait till the deathmatches are over.

IshKebab5• 9 months ago

It's not really that bad. Unless you want to be adventurous you need these tools:

* uv: project management, formatting

* Pyright: type checking

* Pylint: linting (this is probably optional though I would strongly recommend it). Ruff is an option but I don't think it is quite as comprehensive yet.

There are alternatives for those tools but they are pretty clearly the best options at the moment. There's nothing in uv's league, and the only alternatives in Pyright's league is BasedPyright. Hopefully Ty and Pyrefly will be good options in future but I don't think they're ready for production use just yet.

dev_l1x_be• 9 months ago

Is there any meaningful difference between TS and Python?

pjmlp6• 9 months ago

One uses runtimes that ship a state of the art JIT compiler, whereas the other is only now giving the first steps.

Yes there are alternatives to CPython, unfortunely they aren't adopted as much as they should.

bobajeff• 9 months ago

Though, I'm happy with basedpyright and usually disable type checking. It's great to have so many options in language servers for Python now that pylance is locked to vscode.

brianzelip• 9 months ago

See the recent Talk Python podcast featuring some Pyrefly team members, https://talkpython.fm/episodes/show/523/pyrefly-fast-ide-fri...

insane_dreamer2• 9 months ago

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).

giancarlostoro2• 9 months ago

I think the 2nd best IDE for Python for me is Visual Studio proper, not Code. I know it sounds crazy, but Microsoft actually put some effort into their Python integration. Again, its a 2nd best, but that still says a lot about everyone else's editors.

Nowadays I'm finding myself using Zed a lot more, so maybe the story will be that all these nice Rust based tools become baked in giving it super powers for Python.

f311a6• 9 months ago

PyCharm has very basic type checking, though. It's not strict.

pyrefly, ty, pyright, and basedpyright

All of them will complain 2-4x more about your code than PyCharm. I had more than 300 typing errors when I first opened my 20k LOC project in pyright that I wrote in Pycharm.

PyCharm works great when your code is not annotated. It infers types very well. But it won't complain in a lot of cases when your code is annotated.

olejorgenb• 9 months ago

I don't think these are designed to "discovering" complex type inheritances.

They are designed for code which are more or less fully typed, as opposed to PyCharm which cobbles together a bunch of heuristics to try to make sense out of untyped code. An admirable quest, but not one I'm personally interested in.

And their insistence on only supporting this approach drove my entire team away from using PyCharm.

(From shallowly observing notifications on the 20+ typehint related issues I'm subscribed to, they seem to have kinda turned around and working toward fully supporting the python type system finally - possibly by integrating with one of the third-party type-checkers)

IshKebab5• 9 months ago

Are you talking about with code that has proper type annotations? As I recall PyCharm is about the best you can get if you are working with code that has no type annotations but ... you shouldn't be doing that in 2025! With type annotations I've found Pyright to be 100% rock solid.

unmotivated-hmn• 9 months ago

That's interesting. In my experience basedpyright has been better than pyCharm at every turn. Yes, a lot more warnings but generally sensible. One specific thing I remember pissing me off: https://youtrack.jetbrains.com/issue/PY-58665 Still open 2 years later.

rasulkireev2• 9 months ago

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

codethief• 9 months ago

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.)

rasulkireev2• 9 months ago

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.

flanked-evergl6• 9 months ago

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.

phailhaus5• 9 months ago

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.

kstrauser3• 9 months ago

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.

flanked-evergl6• 9 months ago

I don't think this is really true, I think native data classes can do just about everything you need, it's just that you need some tooling around them to get the same as Pydantic offers. I'm pretty sure we are going to see better native dataclass support in Pydantic going forward.

Already there is some support in Pydantic for native dataclasses: https://docs.pydantic.dev/latest/concepts/dataclasses/

ocamoss• 9 months ago

Pyrefly actually does have (experimental) support for Pydantic! https://pyrefly.org/en/docs/pydantic/

flanked-evergl6• 9 months ago

Nice, did not know.

mixmastamyk4• 9 months ago

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

flanked-evergl6• 9 months ago

Pydantic does some pretty strange stuff which works as expected but confuses the type checker unless you use the pydantic plugin. https://docs.pydantic.dev/latest/integrations/mypy/

sirfz3• 9 months ago

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 basedpyright (what I was using) such as auto imports (Ty has experimental support), showing signature/doc when selecting autocomplete options (I think Ty does have this one) and some other features that I can't remember.

One feature that always existed in Jedi (and now also Zuban) is "goto declaration" in Python. It allowed me to goto the "import" instead of the original definition of a function/class which I'm surprised either isn't supported at all (pyright?) or would just do the same thing as "goto definition" (Ty), seems like an obvious oversight imho.

Edit: Also, I wish all these new tools give more importance to such IDE features as much as they do for type checking.

jswny2• 9 months ago

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

ehsanu1• 9 months ago

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

charliermarsh• 9 months ago

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!

sirfz3• 9 months ago

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

screye2• 9 months ago

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 long term stability

BasedPyright is popular because it comes built-in with Cursor and disappears into the background. I have a positive bias towards Astral figuring it out given their track record. But, none of these tools have reached the point of effortlessness just yet.

phplovesong4• 9 months ago

If typechecking is tongue on cheek, why even bother?

alfalfasprout• 9 months ago

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.

kinto3• 9 months ago

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

sirfz3• 9 months ago

Hi, thanks for the links and for opening the goto declaration issue (that's awesome). I will try to dedicate more time into my setup and provide feedback where possible. Looking forward for all the new updates!

sheepscreek• 9 months ago

I much prefer the rigidity of pyrefly. It enforces a standard expectation across the code base, which will lead to less surprises IMO.

whilenot-dev• 9 months ago

The weird Literal promotion makes pyrefly unusable for me, except if I'd avoid Literal types: https://github.com/facebook/pyrefly/issues/742

eqvinox5• 9 months ago

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__.

notatallshaw5• 9 months ago

The standard library does not directly include type hints, they are stored in typeshed: https://github.com/python/typeshed

You can take a look yourself if you think some of them are wrong: https://github.com/python/typeshed/tree/main/stdlib/asyncio

The advantage is type hints can be fixed without needing to release a new version of Python. The disadvantage is there's a lot of code in the standard library that doesn't really consider how to represent it with type hints, and it can be really tricky and not always possible.

I'm surprised to see so many people moving to pyrefly, ty, and zuban so quickly. I was going to wait until some time in 2026 to see which has matured to the point I find useful, I guess some users really find existing solutions actually unworkable.

eqvinox5• 9 months ago

You can take a look yourself if you think some of them are wrong: https://github.com/python/typeshed/tree/main/stdlib/asyncio

Hmm. Presumably mypy and pyrefly use the same ones, but then I don't understand why pyrefly is complaining and mypy isn't:

  ERROR Argument `Future[list[BaseException | Any]]` is not assignable to parameter `future` with type `Awaitable[tuple[Any]]` in function `asyncio.events.AbstractEventLoop.run_until_complete` [bad-argument-type]
     --> xxx/xxx.py:513:33
      |
  513 |         loop.run_until_complete(tasks.gather(*x, return_exceptions=True))
      |                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The definition in typeshed is this:

  def run_until_complete(self, future: _AwaitableLike[_T]) -> _T: ...

…where is it even puling "tuple[Any]" from…

(tbh this is rather insignificant compared to the noise from external packages without type annotations, or with incomplete ones… pyrefly's inferences at the existence of attributes and their types are extremely conservative…)

Too• 9 months ago

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.

natdempk• 9 months ago

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.

kinto3• 9 months ago

(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/).

nprateem• 9 months ago

Just started trying ty with django-types. I got the models typed in a day or so. Still wading through the other 200+ errors in my codebase. But it's fast at least.

cadamsdotcom• 9 months ago

Been using pyrefly since July on a big python build.

It has some things it can’t pick up on - no return after a catch block when all code paths are covered for example - but it’s speedy and the error messages are good enough for Claude to understand and ignore or resolve.

Recommended!

Pyrefly: Python type checker and language server in Rust

Related Stories