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
And if so, is it possible to error and/or issue a diagnostic when it is parsed?
It's been noted in the past that # type: ignore behavior is inconsistent between line- and module-level contexts, and that inconsistency can be confusing for users who only wanted mypy to ignore errors in their module, but unintentionally asked it to ignore the module entirely. This tends to cause tricky failure cases. Issue #14340 goes into some more detail about this, and resulted in a documentation change in #14342, which is good.
However, I recently ran into a related issue where a developer moved a line-level # type: ignore[list-item] statement to the module-level scope, (reasonably) assuming this would ask mypy to ignore only list-item validation errors in the module. Instead, this silently and surprisingly caused the whole module to be ignored. I looked in the relevant documentation and could find no indication that # type: ignore[...] should be valid at the module level. Therefore, unlike the failure case described in #14340, I think this error is possible to catch without changing the behavior of module-level # type: ignore, because the extra [list-item] specifier at the end has no meaning in the module-level context.
If a module-level # type: ignore[...] is never valid, I propose that it should be treated as an error or warning, and mypy should emit a diagnostic and/or halt processing if it encounters such a statement.
Note: While researching this issue, I noticed that the mypy documentation for # type: ignore refers to a statement applied to the whole file as a top-level comment, but this seems to conflict with the definition of top-level code environment given in the Python documentation (What is the “top-level code environment”?). Because of this, I have opted to use the term module-level instead, as it refers to a statement that applies to the entire Python module. If I am wrong about this, please understand that I am referring to what is termed the top-level comment in mypy docs.
The text was updated successfully, but these errors were encountered:
And if so, is it possible to error and/or issue a diagnostic when it is parsed?
It's been noted in the past that
# type: ignore
behavior is inconsistent between line- and module-level contexts, and that inconsistency can be confusing for users who only wantedmypy
to ignore errors in their module, but unintentionally asked it to ignore the module entirely. This tends to cause tricky failure cases. Issue #14340 goes into some more detail about this, and resulted in a documentation change in #14342, which is good.However, I recently ran into a related issue where a developer moved a line-level
# type: ignore[list-item]
statement to the module-level scope, (reasonably) assuming this would ask mypy to ignore onlylist-item
validation errors in the module. Instead, this silently and surprisingly caused the whole module to be ignored. I looked in the relevant documentation and could find no indication that# type: ignore[...]
should be valid at the module level. Therefore, unlike the failure case described in #14340, I think this error is possible to catch without changing the behavior of module-level# type: ignore
, because the extra[list-item]
specifier at the end has no meaning in the module-level context.If a module-level
# type: ignore[...]
is never valid, I propose that it should be treated as an error or warning, and mypy should emit a diagnostic and/or halt processing if it encounters such a statement.Note: While researching this issue, I noticed that the mypy documentation for
# type: ignore
refers to a statement applied to the whole file as a top-level comment, but this seems to conflict with the definition of top-level code environment given in the Python documentation (What is the “top-level code environment”?). Because of this, I have opted to use the term module-level instead, as it refers to a statement that applies to the entire Python module. If I am wrong about this, please understand that I am referring to what is termed the top-level comment in mypy docs.The text was updated successfully, but these errors were encountered: