mypy VS pyright

Compare mypy vs pyright and see what are their differences.


Static type checker for Python (by microsoft)
Our great sponsors
  • Scout APM - Less time debugging, more time building
  • SonarQube - Static code analysis for 29 languages.
  • SaaSHub - Software Alternatives and Reviews
mypy pyright
56 61
13,051 7,935
2.2% 1.8%
9.8 9.9
6 days ago 6 days ago
Python Python
MIT License GNU General Public License v3.0 or later
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.


Posts with mentions or reviews of mypy. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-04-29.


Posts with mentions or reviews of pyright. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-04-29.
  • pylsp with VSCode?
    2 projects | | 29 Apr 2022
    I'm using VSCodium (VSCode without Microsoft's telemetry) which doesn't work with pylance, Microsoft's Python language server. It seems like the two main alternative contenders are pyright and pylsp. I've been trying pyright, which has an extension, but it doesn't seem to support docstrings on all packages. I couldn't find any configuration options for setting an alternative language server in VSCode. Anyone have some tips on how to set up pylsp?
  • How do I configure a linter to check if method signatures are type hinted?
    1 project | | 28 Apr 2022
    While mypy is the (and also my) go-to solution, I recently found pyright but haven't used it yet.
  • Python’s “Type Hints” are a bit of a disappointment to me
    15 projects | | 21 Apr 2022
    Every point in this blog post strikes me as either (1) unaware of the tooling around python typing other than mypy, or (2) a criticism of static-typing-bolted-on-to-a-dynamically-typed-language, rather than Python's hints. Regarding (1), my advise to OP is to try out Pyright, Pydantic, and Typeguard. Pyright, especailly, is amazing and makes the process of working with type hints 2 or 3 times smoother IMO. And, I don't think points that fall under (2) are fair criticisms of type *hints*. They are called hints for a reason.

    Otherwise, here's a point-by-point response, either recommending OP checks out tooling, or showing that the point being made is not specific to Python.

    > type hints are not binding.

    There are projects [0][1] that allow you to enforce type hints at runtime if you so choose.

    It's worth mentioning that this is very analogous to how Typescript does it, in that type info is erased completely at runtime.

    > Type checking is your job after all, ...[and that] requires maintenance.

    There are LSPs like Pyright[2] (pyright specifically is the absolute best, IMO) that report type errors as you code. Again, this is very very similar to typescript.

    > There is an Any type and it renders everything useless

    I have never seen a static-typing tool that was bolted on to a dynamically typed language, without an `Any` type, including typescript.

    > Duck type compatibility of int and float

    The author admits that they cannot state why this behavior is problematic, except for saying that it's "ambiguous".

    > Most projects need third-party type hints

    Again, this is a criticism of all cases where static types are bolted on dynamically typed languages, not Python's implementation specifically.

    > Sadly, dataclasses ignore type hints as well

    Pydantic[3] is an amazing data parsing library that takes advantage of type hints, and it's interface is a superset of that of dataclasses. What's more, it underpins FastAPI[4], an amazing API-backend framework (with 44K Github stars).

    > Type inference and lazy programmers

    The argument of this section boils down to using `Any` as a generic argument not being an error by default. This is configurable to be an error both in Pyright[5], and mypy[6].

    > Exceptions are not covered [like Java]

    I can't find the interview/presentation, but Guido Van Rossum specifically calls out Java's implementation of "exception annotations" as a demonstration of why that is a bad idea, and that it would never happen in Python. I'm not saying Guido's opinion is the absolute truth, but just letting you know that this is an explicit decision, not an unwanted shortcoming.








    15 projects | | 21 Apr 2022
    MyPy isn’t the only checker of course, there’s also Microsoft’s Pyright, among others. Pyright is fast and natively integrated in Microsoft’s Pylance VSCode extension, so these days I use Pyright’s type checking in real time even when I can’t be bothered to set up MyPy (no difficult, just not important for, say, <1000 line scripts).

    15 projects | | 21 Apr 2022
    pyright is a command line program

    in my experience it's a far better type checker than mypy, which tends to silently not check things without you ever realising

  • Language server protocol choice
    1 project | | 21 Mar 2022
    There's nothing to trust, pyright is entirely open source and you can check it yourself:
  • Help with type hints and higher order functions
    2 projects | | 17 Mar 2022
    Turns out it was a bug in pyright - the first example never type checked with mypy. :/
  • Disabling virtual text for only some LSP messages
    2 projects | | 3 Mar 2022
    2 projects | | 3 Mar 2022
    This discussion probably gives more context than I ever could:
  • Pyright – Static type checker for Python
    1 project | | 20 Feb 2022

What are some alternatives?

When comparing mypy and pyright you can also consider the following projects:

jedi-language-server - A Python language server exclusively for Jedi. If Jedi supports it well, this language server should too.

pylance-release - Documentation and issues for Pylance

python-language-server - Microsoft Language Server for Python

coc-jedi - coc.nvim wrapper for


lsp-pyright - lsp-mode :heart: pyright

pyre-check - Performant type-checking for python.

Poetry - Python dependency management and packaging made easy.

black - The uncompromising Python code formatter

coc-pyright - Pyright extension for coc.nvim

Flake8 - flake8 is a python tool that glues together pycodestyle, pyflakes, mccabe, and third-party plugins to check the style and quality of some python code.