If you were setting up CI for a project, department, or company today, would you feel comfortable using Astral's ty as the primary Python type checker, or would you choose basedpyright, Pyright, mypy, Pyrefly, or another alternative? I'm configuring CI for a project and currently leaning toward basedpyright because I've used it for a while. ty has been improving quickly, but as far as I can tell, it still isn't fully on par with the more established checkers. How are people evaluating its stability, feature coverage, and diagnostic churn in real-world CI?
5 Answers
I'd stick with basedpyright for now, especially if you're already comfortable with it. ty is still on a 0.0.x version and its maintainers warn that diagnostics and other behavior can change between releases. That kind of churn can be inconvenient in a production pipeline, even if the checker itself is reliable.
ty is no longer alpha-quality in the sense of constantly crashing or producing wildly unusable results. It has become fairly dependable and can have a similar balance of false positives and false negatives to mature tools. The main concern is still pre-1.0 API and diagnostic instability, so pin the version and expect some maintenance when upgrading.
I use it in CI and haven't had serious problems. The results are predictable enough for our codebase, but we pin versions and run a full pipeline whenever the checker is upgraded.
Some teams are already using ty successfully in CI because it has a relatively low maintenance burden and its editor diagnostics line up well with the CI output. I wouldn't dismiss it outright, but I'd only adopt it after testing it against the project's real code and deciding how much diagnostic churn the team is willing to handle.
For a conservative production setup, basedpyright or Pyrefly seems like the safer choice right now. ty is improving quickly, but it isn't feature-complete and hasn't accumulated the same amount of ecosystem experience as the established alternatives. I'd evaluate it alongside your current checker rather than make it the only gate immediately.
I moved one project from ty to Pyrefly to compare them. It may be worth trying both on your own code, since support and false-positive behavior can vary a lot by project.
The answer depends on the framework and code style. Zuban is another Rust-based option that some people find more mature for general Python, while mypy remains a strong choice for Django because its Django support is still better. Whichever tool you choose, pin the exact version and treat checker upgrades like any other dependency change.
That matches my experience. The recent problems haven't been crashes so much as reports changing whenever a new edge case is covered or an error is renamed.