Hacker News Reader

Comment by olive-n | Hacker News Reader

I feel like pyrefly was gaining some traction over the year. I started using it this week.

This seems like astral realizing they lost the type checker race and now fold it into their popular project so people have a reason to use it.

If it is already installed with uv, people have less reason to look for a type checker and will just stay with the default option.

View on HN

I agree, it sounds like they're trying to expand their moat because they realised they were too late to the better type-checking party.

It's somewhat ironic that they're only just getting around to it actually. The predecessor to `uv`, `rye`, had integration for `ruff` fairly early on - but Astral have really dragged their heels on putting it into `uv` (presumably because `ruff` had already won) and even now aren't adding support until after `ty` is integrated.

Can you elaborate on losing the type checker race?

I am tasked with creating a new baseline for python projects. My first hunch was uv, ty, ruff as I've had a good time with them in the past.

What would you recommend?

The whole python tooling is experiencing kind of a renaissance with new Rust based tools taking over.

These days all my project use uv for project management and ruff for linting and formatting.

I believe there is no obvious default for type checking yet. I use whatever my IDE provides. So e.g. pylance in VSCode, which is build on pyright.

There are currently pretty much 3 projects that I look out for: ty, zuban and pyrefly.

At this point, pyrefly seems to me to be the furthest along with support for many common libraries like pytest, pydantic, django, pandas/polars. And meta actually positions it as a production ready system and not a (pre?)beta. Which is why I decided to test drive it.

I have not directly compared the type checkers, I cannot give you a recommendation. For all I know zuban or ty could be the better choice.

uv and ruff took over because they were in many ways simpler and much faster than the competition. ty does not have that luxury.

To be fair, at least when I tested it on a moderately sized codebase, ty was definitely faster than Pyrefly. Like twice as fast (0.5s vs 1s, give or take). However, it's not really critical to save that half a second for full checks. Both have gradual checking when used as a LSP. And on CI, there is overhead from other things.

However, it remains to be seen to what degree that speed difference is due to ty's smaller feature footprint. It just doesn't seem to check the same things. I found it too permissive, personally.

Pyrefly is better than ty for my use cases. Maybe ty will get there some day.

ty is too permissive when I've tried it. It got better with time, and is maybe even quite ok now, but still, the ideology seems to be to allow anything it doesn't quite understand. Which just doesn't align well with my idea of what a type checker is supposed to do. Pyrefly has much better checks IME (at least with strict mode). On top of that, they have specific support for things like Polars schema checking and array shape checks also (supposedly - haven't tried the latter). Which are just incredible niceties.

It's a good default for a pre-1.0 tool that aims to type check existing code.

Coincidentally, we also went to pyrefly in the last month or so.

With AI able to quickly solve the adoption and migration, it just became a matter of picking the best tool - pyrefly has everything and is faster than ty.

I think with google choosing to go with pyrefly a couple weeks ago it seems to signal that ty ain't it.

Eh I think that’s a pretty uncharitable take.

They did the same thing with ruff too. A totally optional interface through the uv command. Use it or not.

Reply on news.ycombinator.com