python / python/mypy

Support warning on unused ignores without treating them as an error

Open
#12,359 1 comment 14 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

feature topic-type-ignore
Dominant language
Python
Stars
20.6k
Forks
3.3k
PR merge metrics
PR metrics pending

Description

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:

❯ cat test.py
x = 1 + 1  # type: ignore

❯ mypy test.py
Success: no issues found in 1 source file

❯ mypy --strict test.py  # exits nonzero
test.py:1: error: Unused "type: ignore" comment
Found 1 error in 1 file (checked 1 source file)

❯ mypy --strict --no-warn-unused-ignores test.py  # exits zero
Success: 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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the command-line handling illustrated by the --warn-unused-ignores examples and trace how unused-ignore diagnostics affect the exit status. Define the warning, error, and disabled modes while preserving the existing flags, then add coverage for each command-line behavior and verify the documented outputs and exit codes.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
cli, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.