Cloud Parts

Pyright

Microsoft’s open-source static type checker for Python, written in TypeScript, which is also the engine inside the Pylance extension for VS Code.

What it is
Linters, formatters and type checkers (type checkers)
Type
Open source
Made by
Microsoft
License
MIT
Facts checked
9 October 2026

What it is

Pyright follows the official Python typing specification and its conformance tests, and copies mypy’s behaviour where the specification is silent unless it has a reason not to. It was built to sit behind a language server: instead of checking a module top to bottom, it evaluates types lazily, working out the type of any identifier on demand, and its own parser recovers from syntax errors so it keeps working while you type. Its documentation says it is often 3 to 5 times faster than mypy on large codebases. Unannotated code is checked too, by inference. How strict it is depends on typeCheckingMode: off, basic, standard (the default since 1.1.339, December 2023) or strict, with every rule adjustable, set in pyrightconfig.json or [tool.pyright] in pyproject.toml.

The command-line tool is an npm package and needs Node.js; a community-maintained pyright package on PyPI installs Node for you. In VS Code, Microsoft recommends Pylance instead: a closed-source extension built on Pyright that adds features such as semantic highlighting and symbol indexing. Vim, Sublime Text and Emacs use Pyright through language-server plugins, and PyCharm has native Pyright support. basedpyright is a community fork that merges every Pyright release; version 1.1.414 shipped in September 2026.

Why teams pick it

  • Tracks the typing specification closely, and its documentation explains every place it differs from mypy and why
  • Built for editors: lazy evaluation and error-tolerant parsing keep hover, completion and diagnostics fast while you type
  • Checks unannotated code by inference, so it finds bugs before a codebase is fully typed
  • Runs in almost every editor: Pylance in VS Code, plugins for Vim, Sublime Text and Emacs, and native support in PyCharm

Watch out for

  • Needs Node.js; the only official package is on npm, and the PyPI package is a community wrapper
  • Some editor features exist only in Pylance, which is closed source and limited to Microsoft’s VS Code (basedpyright re-implements several of them)
  • It must be pointed at the project’s environment: run outside it, every third-party import shows up as unresolved
  • Newer Rust checkers claim much higher speed: ty says 10 to 60 times faster than mypy and Pyright without caching, and Pyrefly 15 times faster on PyTorch

The Pyright family

1 technologies built from or on Pyright

Alternatives

What all type checkers have in common →

How it fits with other technologies

Pyright 1.1.414 on a Pydantic model, in the project environment · bash

# src/shop/orders.py, line 15:  Order(id="2", total_cents=450)
#                     line 16:  label: str = total(orders)   # total() returns int
uv run --with pyright pyright
# …/shop/src/shop/orders.py:15:55 - error: Argument of type "Literal['2']" cannot be assigned
#   to parameter "id" of type "int" in function "__init__" (reportArgumentType)
# …/shop/src/shop/orders.py:16:18 - error: Type "int" is not assignable to declared type "str"
#     "int" is not assignable to "str" (reportAssignmentType)
# 2 errors, 0 warnings, 0 informations

# Pydantic would quietly convert "2" to 2 at runtime; Pyright holds the model to its annotations.
# With {"typeCheckingMode": "strict"} in pyrightconfig.json, an unannotated
# def parse(raw): return raw["id"]   adds four more errors, starting with:
# …/shop/src/shop/orders.py:20:11 - error: Type annotation is missing for parameter "raw" (reportMissingParameterType)

See it in a real stack

No architecture uses Pyright yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2019–2026

Python got standard type hints with PEP 484, but the reference checker, mypy, was designed for batch runs: it analyses modules top to bottom and relies on the interpreter’s own parser, which stops at the first syntax error. That suits CI better than an editor that has to answer “what type is this?” on every keystroke in a half-written file.

Pyright appeared on GitHub and npm in March 2019, written in TypeScript, mostly by Eric Traut, by far its largest contributor, whose GitHub profile lists Pyright among the projects worked on as a Microsoft Technical Fellow. In June 2020 Microsoft built Pylance, a new VS Code language server, on top of it, so Pyright became the type engine most VS Code Python users run without knowing its name.

In December 2023, version 1.1.339 added the standard mode, between basic and strict, and made it the default, covering the checks the typing standard requires. Community forks such as basedpyright followed, and from 2025 Rust-based checkers from Meta (Pyrefly) and Astral (ty) set out to beat it on speed.

Why it’s built this way

Lazy, just-in-time type evaluation
A language server needs the type of one expression now, not a full pass over the module, so Pyright evaluates only what a query depends on.
Its own error-tolerant parser
Editors are full of half-typed code; recovering from syntax errors keeps diagnostics and completion working, and newer syntax doesn’t depend on the Python version installed.
Check unannotated code by default
Inference gives hover types and catches bugs in code nobody has annotated yet, which matters for a tool most people meet through their editor.
Follow the typing spec, else mypy
Agreeing with the spec and its conformance tests, and with mypy where the spec is silent, keeps code portable between checkers.

Timeline

  1. 2019

    First releases on GitHub and npm, in March

  2. 2020

    Microsoft builds Pylance on Pyright (June)

  3. 2023

    1.1.339 makes the new standard mode the default (December)

  4. 2024

    basedpyright 1.0, a community fork, ships on PyPI

  5. 2025

    Rust-based rivals appear: Meta’s Pyrefly and Astral’s ty

  6. 2026

    Pyright 1.1.414 (September)

Sources11 · facts checked 9 October 2026

Improve this page on GitHub