mypy vs Pyright vs ty: Python Type Checker Comparison (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.

Last updated: May 2026 — mypy 1.15, Pyright 1.1.x, ty 0.x benchmarks.

mypy vs Pyright: The Established Players

Before getting into ty, let’s address the question most Python developers are actually asking: should I use mypy or Pyright?

These two have been the dominant Python type checkers for years. mypy launched in 2012 as the original reference implementation. Pyright arrived in 2019 from Microsoft, written in TypeScript, and quickly became the engine behind VS Code’s Pylance extension. Most teams choosing a type checker today are deciding between these two.

Speed: Pyright Is 2-5x Faster Than mypy

Pyright consistently outperforms mypy on real-world codebases. The gap varies by project size and annotation coverage, but expect Pyright to finish in roughly one-third to one-fifth the time:

On incremental checks (re-checking after a single file edit), Pyright’s on-demand computation model gives it an even larger advantage. mypy re-analyzes entire modules; Pyright recomputes only the types that changed.

Feature Comparison: mypy vs Pyright

Type Coverage Differences

The 40-point conformance gap (58% vs 98%) is the single biggest differentiator. Pyright correctly handles nearly every pattern in the Python typing spec: ParamSpec, recursive types, complex overloads, TypeVarTuple, type guards. mypy struggles with several of these.

In practice, this means Pyright catches bugs that mypy silently misses. On the 40K-line FastAPI project I tested, Pyright found 41 errors vs mypy’s 23. The 18 extra errors included real issues in unannotated functions that mypy skipped entirely because it ignores those by default.

IDE Integration: Pyright vs mypy

Pyright powers VS Code’s Pylance extension, which most Python developers already have installed. You get autocompletion, hover type info, go-to-definition, rename refactoring, and auto-imports with zero configuration. If you use VS Code, you’re likely already running Pyright without knowing it. Pyright also works in Neovim, Emacs, and any editor that speaks LSP.

mypy has no official language server. Editor support comes through third-party extensions like mypy-vscode or running dmypy as a daemon. The experience is noticeably rougher: diagnostics can be stale, auto-imports don’t work, and you often end up running mypy in the terminal separately.

When to Use mypy

• Your CI pipeline and pre-commit hooks are already built around mypy, and the migration cost isn’t worth it
• You depend on mypy plugins, particularly django-stubs, the Pydantic mypy plugin, or SQLAlchemy stubs
• Your team is in a large monorepo where switching type checkers requires coordinating across many teams
• You need mypy’s --strict mode behavior for enforcing full annotation coverage in a specific way

When to Use Pyright

• You’re starting a new project and want the best correctness available today (98% spec conformance)
• You use VS Code and want type checking integrated directly into your editor with no extra setup
• You want faster feedback loops, particularly on larger codebases where mypy’s speed becomes painful
• Your codebase has a mix of typed and untyped code and you want the checker to analyze all of it, not silently skip unannotated functions
• You don’t rely on mypy-specific plugins

For most teams starting fresh in 2026, Pyright is the stronger default. The conformance lead is decisive, the speed is better, and the editor integration is seamless. mypy is still a solid tool, but its advantages are increasingly niche (plugin ecosystem) while its weaknesses (speed, conformance, editor support) are becoming harder to justify.

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. (If you’re moving to Python 3.14, the new t-string Template type gives type checkers a real boundary to enforce on SQL/HTML helpers — useful in any of these checkers.)

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?

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 Pyright faster than mypy?

Yes. Pyright is roughly 2-5x faster than mypy on most codebases. On the home-assistant repo, Pyright finishes a full check in 19.62 seconds vs mypy’s 45.66 seconds. On a 40K-line FastAPI project, Pyright took 8 seconds vs mypy’s 34 seconds. The gap widens on incremental checks because Pyright recomputes only affected types while mypy re-analyzes entire modules.

Should I use mypy or Pyright?

For new projects in 2026, Pyright is the better default. It has 98% typing spec conformance (vs mypy’s 58%), runs 2-5x faster, and integrates directly into VS Code through Pylance. The main reason to stick with mypy is if you depend on its plugin ecosystem (Django-stubs, Pydantic plugin, SQLAlchemy stubs) or have extensive CI infrastructure built around it. If neither applies, Pyright gives you better correctness and a better editor experience.

What is ty and how does it compare to mypy?

ty is a new Python type checker from Astral (the team behind Ruff and uv), written in Rust. It’s 10-60x faster than mypy on large codebases — checking home-assistant in 2.19 seconds vs mypy’s 45.66 seconds. However, ty is still in beta and passes only 53% of typing spec conformance tests compared to mypy’s 58%. ty also lacks mypy’s plugin system. For speed and editor feedback, ty already wins. For correctness and framework support, mypy still has the edge until ty reaches its 1.0 release.

Which Python type checker is best in 2026?

It depends on your priorities. Pyright is the best all-around choice: 98% spec conformance, 2-5x faster than mypy, and seamless VS Code integration. ty is the fastest by far (10-60x over mypy) but still in beta with gaps in type coverage. mypy is the most mature with the best plugin ecosystem but the slowest and least conformant of the three. For most teams, Pyright is the right pick today with ty as the one to watch.

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.