You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Starting with c073712, we started using pyright instead of mypy for type checking in our tests/CI. There were some good reasons for this (outlined in the comments of that commit), but since then we have re-adopted mypy (via #337).
This issue exists to discuss whether we should drop the use of pyright for type checking in our tests and CI.
I'm personally +1 for dropping pyright for the following reasons:
Using pyright adds a Node.js/npm dependency to a project that is otherwise purely Python
mypy seems to be the stricter of the two type checkers, so it's not obvious to me that pyright is adding anything
The text was updated successfully, but these errors were encountered:
I'm +1 on dropping pyright just because of the Node/npm dependency.
I created #382 for the related (but definitely distinct) issue of pytype versus mypy.
Not to mention that life will be better when the minimum python version is 3.10 (sigh...) when the typing system just understand how to handle two types that refer to each other.
I'm generally in favour as well, but I should probably mention that the pre-commit PR includes a commit which adds package.json, package-lock.json and instructions for installing the Node modules.
Starting with c073712, we started using pyright instead of mypy for type checking in our tests/CI. There were some good reasons for this (outlined in the comments of that commit), but since then we have re-adopted mypy (via #337).
This issue exists to discuss whether we should drop the use of pyright for type checking in our tests and CI.
I'm personally +1 for dropping pyright for the following reasons:
The text was updated successfully, but these errors were encountered: