sbp opened a new issue, #375: URL: https://github.com/apache/tooling-trusted-releases/issues/375
As pointed out by @andrewmusselman, we are using mypy type ignore syntax despite having removed mypy from our lints. We pyright instead, which has its own syntax. The reason why we originally continued using mypy syntax is that it's more generic and has more chance of being officially codified in a PEP. This means, however, that our type ignores are not being considered by pyright by category; they are blanket ignores. Our code conventions state that we should use type ignores as seldom as possible, but they are sometimes necessary. We should constrain to category, but we need to decide what format to use. The choice is likely only between mypy + pyright format and pyright format alone. I assume that if combining the formats, as [recommended on `typing.python.org`](https://typing.python.org/en/latest/guides/writing_stubs.html#type-checker-error-suppression-formats), pyright still constrains by category. If only the mypy format is used, it treats it as a blanket ignore. If we do choose the mypy + pyright format, we would have to look up the relevant code in mypy. This could be difficult because we don't support or use mypy anymore. We could enable it again. We could enable it conditionally when needing to supply the relevant code. This would have the advantage of introducing friction when adding type ignores. On the other hand we could also use a blanket `type: ignore` with the pyright format, assuming that pyright still constrains by category even if no mypy category is present. This would ensure that if somebody uses mypy to perform extra checks, the code still works correctly, although it would be missing the full functionality of having a mypy category too. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
