Blog: Choosing a Type Checker for Positron (Python/R Data Science IDE)

Posted by BeamMeUpBiscotti@reddit | Python | View on Reddit | 8 comments

The open-source Python type checker and language server ecosystem has exploded. Over the past couple years, four language server extensions have appeared, each with a different take on what Python type checking should look like.

The Positron team evaluated to decide which one to bundle with Positron to enhance the Python data science experience.

They compared Pyrefly, basedpyright, ty, and zuban along the following dimensions: - Feature completeness - Correctness - Performance - Ecosystem

Read the full blog to see what they chose and why: https://positron.posit.co/blog/posts/2026-03-31-python-type-checkers/

[-]

its_a_gibibyte@reddit

Read the full blog to see what they chose and why:

Absolute epitome of clickbait to drive traffic. If you want to make a post here, just make a post. It doesnt need to be clickbait for another site. For those who don't want to click:

We bundled Pyrefly as Positron’s default Python language server.

The deciding factors:

Pyrefly’s clean design decisions felt like the best fit for Positron. The hover docs are rendered and hyperlinked, with sources for type inference. The type inference catches real bugs without requiring you to annotate everything. While it has the strictest type checking, this is configured to a moderate level by default. It has active development with strong backing. Meta has committed to making Pyrefly genuinely open-source and community-driven, with biweekly office hours and a public Discord. Development velocity is high. It is MIT licensed, which allows us to bundle it into Positron. It wasn’t a runaway winner. Basedpyright is more mature and feature-complete. ty has a lot of long-term potential, especially for ruff users and fans of the gradual guarantee, and is closing feature gaps fast. But for the specific use case of “Python data science in an IDE,” Pyrefly had the best balance of features, UX, and readiness.

[-]

buqr@reddit

Correctness was mentioned as a factor, but the blog doesn't go into any detail as to how that was measured. The Python typing conformance test suite is useful, but I would be more interested to see real world comparisons, attempting to integrate different tools into an existing codebase.

[-]

Deto@reddit

I still run into a bunch of typing errors that I can't fix without type guards when using type checking with the data science stack so I end up turning it off

[-]

Beginning-Fruit-1397@reddit

Like what? I don't have issues personnally. Altough the "data science stack" can be a lot of different things

[-]

Deto@reddit

One I can recall right now is around pandas selectors. Like you can use anything that acts like a bool iterable to select rows/columns but the type spec is more narrow.

[-]

Beginning-Fruit-1397@reddit

Oh I'm not surprised about pandas. It's poorly typed, and not all it's API's are typing friendly anyway. A while ago I wrote a wrapper library just because it was so annoying lmao. I'd just recommend checking out polars or duckdb (I just landed a respectably sized PR that improve a lot the typing of the latter coincidentally). Faster & better in every way

[-]

Beginning-Fruit-1397@reddit

Good post. I use basedpyright but each week try once to run pyrefly/ty to see where it is as a type checker or LSP.

But basedpyright is so much more mature and complete it's not really comparable. I still see pyrefly or ty choke on large unions, complex generics, etc... and lambdas.

On a "raw" type checking run, ty is by far the fastest. I have good hopes that pyrefly will catch up.

When used as an LSP the speed isn't really a factor. As outlined by the article, completion are reasonably fast in all cases. But what I see being the big difference is on long session in fairly large codebases. badedpyright will start to eat a lot of RAM, slow things down, and I periodically have to restart VSCode.

On the largest codebase I worked on, I couldn't even use it, as soon as I was opening one file from the test suite it was crashing (well it was pylance not basedpyright but since the engine is more or less the same I don't expect a meaningful difference). ty on the other hand kept things smooth at all times. But the loss in strictness is a dealbreaker to me. I find the approach from ty meh, and will surely start to use pyrefly once it's more mature and if a "super strict" mode is available (just like basedpyright with ALL rules on)

[-]

totheendandbackagain@reddit

Great blog, super useful write up. Tx