ty vs mypy vs Pyright: Which Python Type Checker Should You Use in 2026?

The main fixture contains nine intentional typed-error categories plus one valid narrowing function. An unresolved import and a valid Python 3.14 t"..." template string live in separate files, so an import or parser problem cannot prevent the core cases from being checked.

from typing import Protocol, TypedDict, overload

def bad_return(value: int) -> str:
    return value                 # incompatible return

bad_return("wrong")             # incompatible argument

maybe_name: str | None = None
maybe_name.upper()              # None member access

class UserRow(TypedDict):
    name: str
    age: int

missing_age: UserRow = {"name": "Ada"}

class Renderer(Protocol):
    def render(self, value: int) -> str: ...

For background and installation details, use the official mypy documentation, Pyright documentation, and ty documentation. The result below is our test, not a restatement of any vendor benchmark.

On the deliberately typed cases, the result was a tie: mypy, Pyright, and ty each caught all nine error categories. None complained about the valid union-narrowing function, and all three accepted the separate Python 3.14 template-string file.

The unannotated function was the useful separator. None of the default runs reported it. mypy --strict raised the total from 9 to 11 by flagging the missing function annotation and the call into untyped code. Pyright strict raised its total from 10 to 17, adding granular unknown parameter, return, and member-type diagnostics.

ty is intentionally not shown with a fake “strict” row. Its current configuration model exposes individual rules and severities rather than one preset directly equivalent to mypy --strict or Pyright typeCheckingMode: "strict". The official mypy/Pyright migration guide for ty explains those differences.

Each default command was started as a new process 11 times against the same three small files on Windows, using an AMD Ryzen 5 3500. The first timed process is separate; the repeated value is the median of the next ten fresh-process runs.

ty was fastest in this setup: its 55.8 ms repeated median was about 4.6× lower than mypy's and 10.2× lower than Pyright's. That is useful for quick CLI feedback, but it is not evidence that the same ratio holds for your repository. This fixture is tiny, startup dominates, earlier diagnostic runs had already warmed OS caches, and no daemon, editor, or incremental workflow was benchmarked.

mypy is the easiest recommendation when a project already has mypy configuration, plugins, suppressions, and CI history. Its error codes were compact and familiar in this run, and --strict made the move from typed islands to annotation coverage obvious. It is also the checker used by our online Python Type Checker, so a small snippet can be checked without local setup.

Choose mypy when: compatibility with an established Python typing workflow matters more than winning a startup benchmark; your framework depends on a mypy plugin; or the team already understands mypy error codes and configuration.

Pyright produced the most detailed strict output here. That can feel noisy in a migration, but it gives a team precise control over unknown types and incomplete annotations. Its command-line package is installed through npm, and its configuration supports named checking modes plus individual diagnostic rules.

Choose Pyright when: fast editor feedback is central to the workflow, the team wants granular rule-by-rule enforcement, or strict unknown-type reporting is more valuable than the smallest terminal output. If switching from mypy, test the real codebase first—the official comparison documents behavioral differences.

ty had the lowest startup-inclusive times and still caught every deliberately typed category in our fixture. Its concise messages were readable, and installation can be as simple as pip install ty. The trade-off is not diagnostic ability in this small test; it is project risk. A newer checker may differ on advanced typing behavior, configuration, editor workflows, plugins, and third-party assumptions built around mypy or Pyright.

Choose ty when: very short feedback loops matter, you can validate it against your own repository, and you are comfortable checking compatibility before replacing an established gate. A practical adoption path is to run ty alongside the current checker first, compare disagreements, then decide whether it can become the gate.

1. Run the candidate checker beside your existing gate; do not replace CI from a generic benchmark.
2. Compare disagreements in your hardest modules: framework code, generated code, stubs, overloads, and untyped boundaries.
3. Choose a strictness baseline deliberately, then reduce exceptions over time instead of enabling every rule blindly.
4. Measure both clean runs and the editor or incremental loop developers actually feel.

mypy --python-version 3.14 --show-error-codes core_cases.py missing_import.py python314_syntax.py
mypy --python-version 3.14 --strict --show-error-codes core_cases.py missing_import.py python314_syntax.py

pyright --pythonversion 3.14 core_cases.py missing_import.py python314_syntax.py
pyright --project pyrightconfig.strict.json

ty check --python-version 3.14 core_cases.py missing_import.py python314_syntax.py

The evidence records exact versions, configuration, diagnostic outputs, all 11 timing samples, and the test machine. The important limits are equally explicit: one Windows machine, three tiny files, startup-heavy fresh processes, warmed OS caches, and no large-project, daemon, incremental, editor, plugin, or third-party-stub benchmark.

Before choosing, replace our fixture with your own modules. If you only need to inspect a function or reproduce a mypy error quickly, open the Python Type Checker. For style and correctness rules outside static typing, use the Ruff Playground as a separate linting step.