[_fdsfs12123]

Has anyone had to choose between Mypy and Pyright? Which is "better"?

A couple years ago I was in charge of choosing between the two, and I somewhat flippantly chose Pyright because it felt a lot faster (<5 second to do 30k lines) and had an easy integration with the editors people use at work (Pylance, coc-pyright).

Later, I realized that some popular libraries we use (django, numpy) have dedicated plugins for Mypy that you can't use with Pyright. So you have to look for Pyright-friendly type stubs or roll your own.

I've generally liked Pyright (as a side note, they have super responsive maintainers - ask a question on their GH, and they usually answer within a few hours), but I've been wondering if I am missing out with Mypy.

[davepeck]

At least today, my experience is that Pyright is faster, flags more issues, provides better error messages, and (alas for Mypy) has fewer bugs. I hope this will change over time as Mypy matures, but there you have it.

When using Pyright in large Django projects, it's helpful to add explicit type annotations in a number of places (like reverse relations in Models) but I've found this tends to improve the clarity of the resulting code anyway.

[strokirk]

Pyright doesn’t really support a lot of big libraries, like Django, so if you want to use them you’re out of luck.

[veber-alex]

pyright and ruff are my new go to python tools, replacing mypy, pylint, isort and black.

So far the only thing that bothers me about pyright is that it can't infer the type of collections based on later insertions.

So in something like:

  lst = []
  lst.append(1)

lst is of type list[Any]

I also program in Rust so I kinda expect this to work :P

I asked the maintainer about this and this is apparently by design, though mypy handles this correctly IIRC.

[js2]

Ruff is not a replacement for black[^1]. It's also currently complementary to pylint, not a replacement[^2]. I still use those tools with ruff.

Further, out of the box, ruff doesn't even replace isort. You have to specifically enable it to sort imports (`I`)[^3].

I personally think that ruff's defaults are much too conservative. I configure it with `ALL` and then ignore the rules I don't want. I _want_ upgrades of ruff which add new rules to find new things. I'll never know about the new rules if I have to follow its development. I fully expect `pre-commit autoupdate` to cause me some pain after I run it, and that's okay. Linters adding new rules are usually helping me make my code cleaner.

[^1]: https://docs.astral.sh/ruff/faq/#is-ruff-compatible-with-bla...

[^2]: https://docs.astral.sh/ruff/faq/#how-does-ruff-compare-to-py...

[^3]: https://docs.astral.sh/ruff/rules/#isort-i

[0xFF0123]

Although it's in alpha, Ruff does have a replacement for Black. https://github.com/astral-sh/ruff/blob/main/crates/ruff_pyth...

[cosmojg]

What does your pyproject.toml (or equivalent) look like? Which linters, formatters, and similar tools do you consider essential to your Python development workflow?

[rhaps0dy]

Pyright is great, and IME does more inference than Mypy and flags more errors.

Mypy is catching up on speed though! Can't say I've tried any plugins.

[IshKebab]

Pyright is much better.

It is much better written, much more correct, has fewer bugs, and it is the default in VSCode so less friction to set up.

In my experience it isn't hugely faster so I wouldn't say that is a big factor. The main benefit is that it is just very correct and has very few bugs (and when there are bugs they are fixed very quickly).

I would avoid Mypy if at all possible. I once tried to fix a bug in it and the codebase was very very hairy. Partly that's because it predates official type hinting support, and partly because it supports a load of hacks to allow incorrect types. Sometimes even the way you write the type affects how it is interpreted (e.g. `a # type: foo` is different to `a: foo`).

The only times I would choose Mypy is if you really need one of those plugins you mentioned, or if you are adding types to a legacy codebase and can't face seeing how bad it really is.

[gen220]

`mypy` originally had first-mover advantage, `pyright` has late-mover advantage.

Now that we're in the mid-to-late stage of Python typecheckers, `pyright` has a better intercept and slope than `mypy`.

I think there'll be one last typechecker to rule them all written in Rust – but we're not there yet, so use `pyright`.

[guappa]

Why would a typechecker written in rust be able to implement a different logic than one written in any other language?

And one written in python could just use python for the grammar so it would have the advantage of always loading the code the same exact way as python does.

[0xFF0123]

It would be significantly faster

[globular-toast]

For Django there is django-types, a fork of django-stubs that works without the mypy plugin. There might be similar for numpy.

[maximilianroos]

For those using mypy and wishing it were a bit faster — dmypy is really good.

I often leave this running, so I can see live errors on every save:

    watchexec -rc -e py -- dmypy run

[kps]

I don't touch Python much, so last time I wrote something, I used mypy and pyright and pylint and ruff.

[kelsolaar]

We started with Mypy for thr colour-science.org projects but Pyright is so much faster that it is hard to look back. We have no particular issue with Numpy. As you pointed out the devs, especially Eric Traut, are really responsive.

[guappa]

Last I tried it, pyright had several false positives that didn't affect mypy. So I remained with mypy.