Replies: 3 comments 1 reply
-
Related to #29 |
Beta Was this translation helpful? Give feedback.
-
These reasons have me intrigued. On a quick look my main concern is if you I have node and pyright installed for my lsp (I don't use VS Code so no pylance) so this isn't a big deal for me. But I could see it being a barrier to entry for contributions on an open source project from Python developers that want nothing to do with node/js. |
Beta Was this translation helpful? Give feedback.
-
The supposed speed differences between mypy and pyright would only be noticeable for really large codebases. Also, the recursive type checks and such are useful for projects that require that kind of complexity. I think it's best to keep this on the backburner for now. I've wanted to try out pyright for a while now, but this repo may not be the best place to do it 😅. Let's keep this open for future reference anyway. |
Beta Was this translation helpful? Give feedback.
-
For CI and command line type checking, it makes sense to explore pyright a bit more, especially as they've been continually updating this page.
There's enough evidence that pyright has significantly improved from its earlier days, and it's also likely to be faster than mypy and it's very actively being maintained and improved.
This particular claim from this Dagster blog is one I'd like to test in the future:
I think those reasons of rapid responses to bugs and handling recursive types is why Pydantic made the choice to base their checks on pyright and not mypy.
Beta Was this translation helpful? Give feedback.
All reactions