[Mehdi2277]

For a while I used both mypy and pyright for my team’s codebase. After about half a year I eventually dropped mypy . I think type checking is valuable just that most of errors mypy detected pyright also caught and using newer type features often led to mypy false positives. I had trouble justifying using both when I could require my teammates to install pyright. Advanced type features tend to run into more bugs and while both are well maintained, pyright’s maintenance is magical. I do not know any other open source library that fixes bugs as fast (most bugs are fixed in under a week). The main thing that eventually forced decision was a flaky (depends on cache) mypy crash using paramspecs half a year ago. At time paramspec support was still in progress and there’s a good chance that specific issue is fixed.

The main awkwardness of pyright is it’s node library and most python devs I work with don’t interact much with node. But my team has a bash script that installs all our dependencies including node as needed (nvm) which mostly works. One benefit is you can use pyright as an LSP and it works very convenient in vscode.

Edit: 3rd party library lacking types is probably biggest issue. As my codebase is mostly typed by itself I’ve started gradually writing type stubs for library apis we use. Only writing stubs for small percent of what we use helps but there’s still a ton to add given codebase was started without types.

[charliermarsh]

Woah, Pyright is written in Node? And it has its own [parser](https://github.com/microsoft/pyright/blob/b74be3b2cb2c5d35b9...)? That's really interesting. I wonder how it compares to Mypy on speed.

> The main thing that eventually forced decision was a flaky (depends on cache) mypy crash using paramspecs half a year ago. At time paramspec support was still in progress and there’s a good chance that specific issue is fixed.

I actually think I ran into this exact issue (ParamSpec-related, only fails when reading from cache, etc.), which led me to pin a Mypy development version for a while and was fixed recently.

[anuragsoni]

> I wonder how it compares to Mypy on speed.

I use pyright at work at my current job, and used mypy at my previous job. Pyright has been better in almost every aspect in my experience. Its been more robust, and performs a lot better than mypy at type-checking in a fairly large mono-repo.

[andrewingram]

In my experience, the biggest issue with not using mypy, is the number of mypy plugins you lose access to. It's not uncommon for projects (or their ecosystems) that rely heavily on metaprogramming to provide mypy plugins to shore up the gaps in the type system; e.g. Django, strawberry, pydantic.

But other than that, I generally prefer pyright day-to-day because the experience using VSCode is far better.