ty vs mypy vs pyright: Which Python Type Checker Wins in 2026?

TL;DR

ty from Astral (the Ruff and uv team, now owned by OpenAI) type-checks Python projects 10-60x faster than mypy or pyright. But it currently passes only 53% of the typing spec conformance tests, less than mypy’s 58% and far below pyright’s 98%. If you need raw speed and can tolerate gaps, ty is worth watching. If you need correctness and broad library support right now, pyright is the safest bet. mypy still works fine if you’re already on it, but there’s no reason to start a new project with it in 2026.

Python Has Four Type Checkers Now

For over a decade, Python type checking meant mypy. Then Microsoft’s pyright showed up in 2019, brought real speed improvements, and became the backbone of VS Code’s Pylance extension. That two-horse race was comfortable enough.

2025 changed things. Meta announced Pyrefly in alpha in May 2025, a Rust-based type checker built by their Python Language Tooling team. Then in December, Astral (set to join OpenAI following the acquisition announced in March 2026), the company behind Ruff and uv, released ty. Python developers now have four options, two of them less than a year old.

I’ve spent three weeks running all three major checkers (ty, mypy, pyright) across real projects: a FastAPI backend, a Django monolith, and a data pipeline built on Polars.

Speed: ty Is in a Different Category

Here are the numbers. The home-assistant and PyTorch figures come from Astral’s published benchmarks; the Django figure comes from independent third-party testing:

That incremental number is the one you feel in daily work. When you edit a file in a large codebase and your editor takes 370ms to re-check (pyright) or several seconds (mypy), the delay breaks your flow. At 4.5ms, ty’s feedback is effectively instant.

The speed comes from Rust, but also from architecture. ty was built from scratch as a language server with fine-grained incremental analysis. When you change one function, it recomputes only the affected dependency graph. mypy re-analyzes whole modules. pyright computes types on demand, which helps, but ty’s approach is more granular.

Conformance: ty’s Weak Spot

Fast checking doesn’t help if the checker misses real bugs. The Python typing spec has a conformance test suite with 139 tests covering everything from basic generics to edge-case type narrowing. Scores as of March 2026:

ty currently passes fewer conformance tests than mypy, the tool it’s trying to replace. Pyright sits at 98% — nobody else is close.

A few caveats. First, not all conformance tests are equally important. Some cover obscure edge cases you’ll never hit in a typical web app or data pipeline. Second, ty is in beta. Astral has a track record of shipping fast (Ruff went from zero to industry standard in about a year). Third, most of ty’s failures come from unimplemented checks rather than incorrect results.

But if your codebase uses advanced typing patterns (Protocol classes, ParamSpec, recursive types, complex overloads), ty will miss things that pyright catches. For now.

How They Handle Untyped Code

Most Python codebases aren’t fully annotated. So what happens when the checker encounters a function with no type hints?

mypy skips unannotated functions entirely by default. You need --check-untyped-defs or --strict to change this. This means mypy gives you a false sense of coverage. It reports “no errors” when it’s actually ignoring half your code.

pyright checks everything, including unannotated functions, using inferred types. It offers four strictness levels (off, basic, standard, strict), with “standard” as the default. This can produce false positives in highly dynamic code, but it’s honest about what it finds.

ty checks all code but follows a “gradual guarantee,” where unknown types are treated permissively. The practical effect: adding type annotations to working code never introduces new erors. A good default for teams migrating incrementally. You won’t get a wall of 500 errors on day one.

IDE Integration

If you spend eight hours a day in your editor, this matters as much as raw speed.

VS Code users already have pyright built in through the Pylance extension. Autocompletion, hover info, go-to-definition, rename refactoring — all work out of the box. You’ve probably been using pyright without knowing it.

ty ships its own LSP and a VS Code extension on the marketplace: go-to-definition, find references, completions with auto-import, rename, inlay hints, signature help. It’s polished for a beta. The auto-import suggestions are good, and the diagnostic messages are clearer than pyright’s in many cases.

mypy has no built-in language server. Editor integration relies on third-party plugins like mypy-vscode or dmypy. It works, but you feel the seams: often you’re running mypy in the terminal while your editor shows stale results.

Plugin Support and Framework Integration

mypy has the richest plugin collection. Django-stubs, Pydantic’s mypy plugin, SQLAlchemy stubs. If you use a major Python framework, there’s probably a mypy plugin for it. This is the strongest argument for staying on mypy in 2026.

pyright doesn’t support plugins, but its aggressive type inference handles many framework patterns natively. Pydantic v2 works well with pyright out of the box. Django support is decent through django-stubs but not as smooth as with mypy.

ty has no plugin system yet. Astral has stated that Pydantic and Django support are priorities for the stable 1.0 release. Until then, if your project leans heavily on framework-specific typing magic, ty will produce false positives or miss real errors in those areas.

Real Migration: What Switching Looks Like

I ran all three on a mid-size FastAPI project (~40K lines, ~60% annotated):

# Install and run each
uv tool install ty@latest
ty check src/

pip install mypy
mypy src/ --check-untyped-defs

pip install pyright
pyright src/

mypy found 23 errors in 34 seconds. Most were legitimate: missing return types, incompatible argument types in Pydantic model validators.

pyright found 41 errors in 8 seconds. The 18 extra errors were a mix of real issues mypy missed (because it skipped unannotated functions) and a handful of false positives in dynamic FastAPI dependency injection.

ty found 14 errors in 0.8 seconds. Fewer errors than mypy, because ty hasn’t implemented all the checks yet. Every error it reported was real though. No false positives.

At 40K lines, the speed gap barely matters. But scale to a 500K-line Django monolith, and the gap between 0.8 seconds and 34 seconds is the difference between running the checker locally before every commit and deferring it to CI.

Which Should You Pick?

flowchart TD
    A[New Python project?] -->|Yes| B{Speed top priority?}
    A -->|No, existing codebase| C{Currently using mypy?}
    B -->|Yes, and okay with beta gaps| D[ty]
    B -->|No, need full coverage| E[pyright]
    C -->|Yes, working fine| F[Stay on mypy]
    C -->|Yes, but too slow| G{Heavy framework plugins?}
    G -->|Yes, Django/Pydantic| H[Stay on mypy, watch ty]
    G -->|No| I[Switch to pyright or try ty]
    C -->|No| E

Pick pyright if: you want the best correctness-to-speed ratio right now, use VS Code, or need a type checker that’s both fast and thorough. It’s 2-5x faster than mypy (depending on codebase) with 98% spec conformance. For most teams in 2026, this is the right default.

Pick ty if: you’re starting a new project and speed is your top priority, your codebase is partially typed and you want gradual adoption without noise, or you’re already in the Astral toolchain (Ruff + uv) and want everything from one vendor. Just know it’s still in beta, and some checks aren’t there yet.

Stay on mypy if: your CI pipeline is built around it, you depend on mypy plugins (Django-stubs, SQLAlchemy), or you’re in a monorepo where switching cost is high. There’s no urgent need to migrate. mypy still catches real bugs. But don’t start new projects on it.

FAQ

Is ty better than mypy?

ty is 10-60x faster on large codebases. But “better” depends on your needs. ty currently passes fewer typing spec tests (53% vs mypy’s 58%) and lacks plugin support for frameworks like Django. For speed and editor experience, ty wins. For correctness and library compatibility, mypy still has the edge.

Which Python type checker is fastest?

ty from Astral is the fastest by a large margin. On the home-assistant repo, ty finishes in 2.19 seconds vs pyright’s 19.62 seconds and mypy’s 45.66 seconds. Incremental checks after a file edit take 4.5ms in ty vs 370ms in pyright.

Should I switch from mypy to ty?

Not yet if you rely on mypy’s plugin collection (Django-stubs, Pydantic plugin). ty is in beta and doesn’t have plugin support. If you don’t use plugins and speed matters, try ty alongside mypy. Run both in CI for a few weeks and compare what each catches. Switch fully once ty reaches its stable 1.0 release later in 2026.

What is the difference between mypy and pyright?

mypy is the original Python type checker (2012), written in Python, with plugin support and broad library compatibility. pyright is Microsoft’s alternative (2019), written in TypeScript, roughly 2-5x faster depending on codebase, with 98% typing spec conformance vs mypy’s 58%. pyright powers VS Code’s Pylance extension. The biggest behavioral difference: mypy skips unannotated functions by default while pyright checks everything.

Is ty ready for production?

ty is in beta. For CI/CD type checking of a fully annotated codebase, it’s not ready yet. It misses too many checks. For editor-time feedback on a partially typed codebase, it’s already useful. Astral’s track record with Ruff and uv suggests the stable release will close the gaps quickly. Watch the conformance numbers over the next few months.

Bottom Line

Competition between Astral, Microsoft, and Meta is pushing all three tools forward fast. ty’s incremental checking at 4.5ms would have seemed impossible two years ago.

My recommendation: use pyright as your primary checker and keep an eye on ty. Install the ty VS Code extension to get its speed benefits during editing, but run pyright in CI for the thorough coverage. When ty hits its planned 1.0 release and closes the conformance gap, you’ll be ready to switch. Teams already using Ruff and uv will likely adopt ty once it matures. Astral’s track record suggests that won’t take long.