Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
asottile opened this issue Apr 3, 2021 · 9 comments
Open

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

asottile opened this issue Apr 3, 2021 · 9 comments

Comments

@asottile
Copy link
Member

asottile commented Apr 3, 2021

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
Copy link
Member Author

asottile commented Apr 3, 2021

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
Copy link
Member Author

asottile commented Apr 3, 2021

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
Copy link
Member Author

asottile commented Apr 3, 2021

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
Copy link

pawamoy commented Apr 6, 2021

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
Copy link
Member Author

asottile commented Apr 6, 2021

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
Copy link

pawamoy commented Apr 6, 2021

Oh OK, thank you for this information @asottile!

@LeXofLeviafan
Copy link

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).

@Avasam
Copy link

Avasam commented Nov 24, 2024

I'd like to see this as well, but will add that I'd like a way to specify that certain codes or groups are outside of Flake8 (from other tools). I've implemented that feature in flake8-noqa, but there's been no acknowledgment from the author since last year: plinss/flake8-noqa#30

@sigmavirus24
Copy link
Member

@Avasam no. Those tools should have instead created their own comment prefix. They could have read from Flake8 if they desired but created their own prefix to avoid this issue and chose not to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants