4 ms·

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

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.

maximilianroos 3y ago
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
rhaps0dy 3y ago
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.
globular-toast 3y ago
For Django there is django-types, a fork of django-stubs that works without the mypy plugin. There might be similar for numpy.
kps 3y ago
I don't touch Python much, so last time I wrote something, I used mypy and pyright and pylint and ruff.
strokirk 3y ago
Pyright doesn’t really support a lot of big libraries, like Django, so if you want to use them you’re out of luck.
kelsolaar 3y ago
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.
davepeck 3y ago
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.
IshKebab 3y ago
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.
veber-alex 3y ago
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 3y ago
  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-black https://docs.astral.sh/ruff/faq/#is-ruff-compatible-with-bla... [^2]: https://docs.astral.sh/ruff/faq/#how-does-ruff-compare-to-pylint https://docs.astral.sh/ruff/faq/#how-does-ruff-compare-to-py... [^3]: https://docs.astral.sh/ruff/rules/#isort-i https://docs.astral.sh/ruff/rules/#isort-i
  - cosmojg 3y ago
    What does your pyproject.toml (or equivalent) look like? Which linters, formatters, and similar tools do you consider essential to your Python development workflow?
  - 0xFF0123 3y ago
    Although it's in alpha, Ruff does have a replacement for Black. https://github.com/astral-sh/ruff/blob/main/crates/ruff_python_formatter/README.md https://github.com/astral-sh/ruff/blob/main/crates/ruff_pyth...
gen220 3y ago
`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 3y ago
  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 3y ago
    It would be significantly faster
guappa 3y ago
Last I tried it, pyright had several false positives that didn't affect mypy. So I remained with mypy.

maximilianroos 3y ago

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

rhaps0dy 3y ago

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.

globular-toast 3y ago

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

kps 3y ago

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

strokirk 3y ago

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

kelsolaar 3y ago

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.

davepeck 3y ago

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.

IshKebab 3y ago

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.

veber-alex 3y ago

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 3y ago
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-black https://docs.astral.sh/ruff/faq/#is-ruff-compatible-with-bla... [^2]: https://docs.astral.sh/ruff/faq/#how-does-ruff-compare-to-pylint https://docs.astral.sh/ruff/faq/#how-does-ruff-compare-to-py... [^3]: https://docs.astral.sh/ruff/rules/#isort-i https://docs.astral.sh/ruff/rules/#isort-i
- cosmojg 3y ago
  What does your pyproject.toml (or equivalent) look like? Which linters, formatters, and similar tools do you consider essential to your Python development workflow?
- 0xFF0123 3y ago
  Although it's in alpha, Ruff does have a replacement for Black. https://github.com/astral-sh/ruff/blob/main/crates/ruff_python_formatter/README.md https://github.com/astral-sh/ruff/blob/main/crates/ruff_pyth...

gen220 3y ago

`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 3y ago
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 3y ago
  It would be significantly faster

guappa 3y ago

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