Raise errors when "# noqa" lines don't have any issues

[asottile]

In GitLab by @OddBloke on Jul 27, 2017, 06:27

Please describe how you installed Flake8

On Ubuntu Artful:

$ apt install flake8

Please provide the exact, unmodified output of flake8 --bug-report

{
  "dependencies": [
    {
      "dependency": "setuptools",
      "version": "36.0.1"
    }
  ],
  "platform": {
    "python_implementation": "CPython",
    "python_version": "3.5.3+",
    "system": "Linux"
  },
  "plugins": [
    {
      "plugin": "mccabe",
      "version": "0.6.1"
    },
    {
      "plugin": "pycodestyle",
      "version": "2.3.1"
    },
    {
      "plugin": "pyflakes",
      "version": "1.5.0"
    }
  ],
  "version": "3.2.1"
}

Please describe the problem or feature

I would like to be able to instruct flake8 to error out when a "# noqa" comment doesn't cause an error to be ignored. This would help us keep our codebase as flake'd as possible, because we'd be forced to remove linting ignores as they are fixed or become irrelevant.

As a specific example, we have code which currently causes an F401 because the imports are only used in Python typing comments. A reductive case:

from typing import Optional  # noqa: F401

def foo():
    # type: () -> Optional[int]
    ...

Once #118 has been addressed, this line should no longer be raising an F401, so I would like to be forced to remove the noqa comment. (This would then mean, after the removal, that we would correctly catch the addition of unused typing imports.)

[asottile]

In GitLab by @sigmavirus24 on Aug 1, 2017, 04:45

This makes good sense. I'm not sure when #118 will be addressed but this shouldn't be blocked on this.

[asottile]

In GitLab by @OddBloke on Aug 1, 2017, 07:21

@sigmavirus24 I had a cursory look around the code to work out how to do this, and I couldn't really figure out where it would fit in. Do you have a high-level idea of how this would be implemented that I could have a stab at?

[asottile]

In GitLab by @asottile on Oct 24, 2018, 07:39

somewhat related, I made a tool to automatically rewrite these but hope to obsolete it by implementing this issue once I'm more familiar with the codebase: yesqa

[pawamoy]

There's also flake8-noqa, that I find very promising 🙂
If all plugins let flake8 itself handle noqa comments, flake8-noqa is perfect. It's currently not the case, for example I had issues with flake8-docstrings, which uses pydocstyle, and D107 noqa comments or violations were "caught" before flake8-noqa could see them, so it reported invalid noqa comments (no violations). Well, I'm not sure to understand how all this works together, I'll have to dig a bit more 🙂

[asottile]

flake8-noqa reaches into internals and will break in the future so I wouldn't suggest using that. as for the flake8-docstrings issue, pydocstyle has their own (incorrect and incompatible) view of noqa which was recently fixed in flake8-docstrings (so now only flake8 handles those comments). if you upgrade flake8-docstrings and pydocstyle you shouldn't have an issue there.

[pawamoy]

Oh OK, thank you for this information @asottile!

[LeXofLeviafan]

I would like to be able to instruct flake8 to error out when a "# noqa" comment doesn't cause an error to be ignored. This would help us keep our codebase as flake'd as possible, because we'd be forced to remove linting ignores as they are fixed or become irrelevant.

This should probably be an optional feature (either opt-in or opt-out); otherwise some developers are bound to get increasingly annoyed by an error check that they have no choice but to constantly enable/disable for the same line if they edit the file frequently enough (F401 being a good example of such an error).