Repository navigation
Raise errors when "# noqa" lines don't have any issues #603
Description
In GitLab by @OddBloke on Jul 27, 2017, 06:27
Please describe how you installed Flake8
On Ubuntu Artful:
$ apt install flake8Please 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.)
Activity
asottile commentedon Apr 3, 2021
In GitLab by @sigmavirus24 on Aug 1, 2017, 04:45
This makes good sense. I'm not sure when
#118will be addressed but this shouldn't be blocked on this.asottile commentedon 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 commentedon 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 commentedon 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 commentedon 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
noqawhich 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 commentedon Apr 6, 2021
Oh OK, thank you for this information @asottile!
LeXofLeviafan commentedon Sep 30, 2023
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 (
F401being a good example of such an error).Avasam commentedon 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 commentedon Nov 25, 2024
@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.