I'm choosing between two Python tooling stacks: Ruff with Ty, or Ruff with Pyrefly. I'd like to hear what people are actually using and how the trade-offs look in practice. When is Pyrefly's additional setup worthwhile? Is Ty capable enough for most real-world projects, or are important features still missing? Do these tools mainly differ in implementation and maturity, or do they follow fundamentally different type-checking philosophies?
5 Answers
My rule of thumb would be: choose Ty when you want a fast, lightweight developer experience and your project’s dependencies are well supported; choose Pyrefly when you want a more mature standalone checker or need better coverage for frameworks such as Django and Pydantic. For very demanding repositories, compare both with basedpyright on representative code and keep whichever produces the fewest incorrect results. Pin whichever version you deploy and review upgrades rather than treating the tool as interchangeable infrastructure.
There is still a strong case for basedpyright or Pyright in production. Several people find that both newer checkers struggle with type narrowing, callable generics, unions, or language-server features in difficult codebases. If false positives are costly, run a trial on your actual repository instead of choosing based on benchmarks or version numbers. Ruff handles linting and formatting; Ty, Pyrefly, Pyright, and mypy are competing ways to handle static typing, so they are not complementary by default.
I use Ruff with Pyrefly and don’t find the setup especially complex. It is a standalone executable, installs cleanly, and has been fast and reliable for both work and personal projects. The extra complexity is mostly deciding which checker fits your codebase, not maintaining a complicated toolchain. For a large project, or one where correctness and broad feature support matter more than adopting the newest tool, Pyrefly is a reasonable default.
The biggest difference right now is maturity rather than the problem they solve. Both are static type checkers, but Ty is still evolving quickly and uses pre-1.0 versioning, so diagnostics and supported features can change. That may be fine for local development if you pin versions, but I’d be cautious about making it the only checker in a company’s CI pipeline. Pyrefly is further along in that respect, though neither necessarily handles every codebase better than established options such as Pyright or basedpyright.
Pre-1.0 does not automatically make a tool unusable for internal development. Pinning the version and testing upgrades can make Ty perfectly reasonable, especially when its speed and integration fit the project.
For many ordinary projects, Ruff plus Ty is a pleasant and fast setup, but check its feature coverage against your dependencies before switching. Pydantic support and some advanced typing constructs are commonly mentioned gaps, and projects using libraries with dynamic behavior may encounter missing inference or false negatives. If the codebase depends heavily on Pydantic, Django, complex generics, or data-science libraries, Pyrefly or a mature Pyright variant may be the safer choice.
This is especially important for libraries such as Polars. A checker can look great on a small application and still produce incorrect diagnostics or miss important types in a heavily typed dependency ecosystem.
A practical compromise is to use the faster newer checker locally and keep a more established checker in CI, but only if their diagnostics do not create confusing or contradictory feedback. Test that workflow before committing to it.