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
Mypy's --warn-unused-ignores option currently treats unused ignores as an error, rather than merely warning about them but still exiting zero.
Mypy should support an option where unused ignores are still warned about in the output, but are not treated as an error.
Current behavior:
❯ cat test.pyx = 1 + 1 # type: ignore
❯ mypy test.pySuccess: no issues found in 1 source file
❯ mypy --strict test.py # exits nonzerotest.py:1: error: Unused "type: ignore" commentFound 1 error in 1 file (checked 1 source file)
❯ mypy --strict --no-warn-unused-ignores test.py # exits zeroSuccess: no issues found in 1 source file
The current warn-unused-ignores behavior, where you have to choose between either erroring or total silence when there's an unused ignore (and can't actually just get a warning), could even be considered a bug.
Pitch
To preserve backward compatibility, perhaps something like this would work:
❯ mypy --unused-ignores=warning # emit a warning but don't exit nonzero
❯ mypy --unused-ignores=error # emit an error and exit nonzero, same as --warn-unused-ignores now
❯ mypy --warn-unused-ignores # same as --unused-ignores=error
❯ mypy --unused-ignores=none # no output, exit zero, same as --no-warn-unused-ignores now
❯ mypy --no-warn-unused-ignores # same as --unused-ignores=none
And the mypy -h usage output would just steer people toward using the new, less confusing options. Potentially using the old options could emit a message like "This option is deprecated, please use <new option> instead", if we may want to remove the confusing options at some point in the future.
The text was updated successfully, but these errors were encountered:
Worth mentioning that mypy's current warn-unused-ignores behavior combines with #12358 (can only use type: ignore, not mypy: ignore) to make it harder to use mypy with other type checkers:
Suppose I am using two type checkers on the same codebase, and one of the type checkers is mypy. I have mypy's "warn-unused-ignores" option enabled, and I have the equivalent option enabled for the other type checker.
For a given line of code, mypy is emitting an error which is a false positive, and the other type checker is not emitting an error for that line.
If I add a type: ignore to that line (with a link to the false positive bug in mypy so I remember to remove the type: ignore once the bug is fixed), my codebase will type check with mypy successfully. But the other type checker will error with an "unused type ignore" error.
If I remove the type: ignore from that line, my codebase will type check with the other type checker successfully, but not with mypy, due to the false positive bug.
To play nicely with other type checkers in the light that different type checkers have different false positive bugs, all type checkers should support both a way to warn-but-not-error on unused ignores, as well as supporting an ignore syntax specific to only that type checker (e.g. "mypy: ignore").
Feature
Mypy's
--warn-unused-ignores
option currently treats unused ignores as an error, rather than merely warning about them but still exiting zero.Mypy should support an option where unused ignores are still warned about in the output, but are not treated as an error.
Current behavior:
The current
warn-unused-ignores
behavior, where you have to choose between either erroring or total silence when there's an unused ignore (and can't actually just get a warning), could even be considered a bug.Pitch
To preserve backward compatibility, perhaps something like this would work:
And the
mypy -h
usage output would just steer people toward using the new, less confusing options. Potentially using the old options could emit a message like "This option is deprecated, please use <new option> instead
", if we may want to remove the confusing options at some point in the future.The text was updated successfully, but these errors were encountered: