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

file-level noqa should raise an error if specific errors are provided (to avoid confusion) #1793

Open
bagerard opened this issue Jan 29, 2023 · 9 comments

Comments

@bagerard
Copy link
Contributor

how did you install flake8?

pip install flake8

unmodified output of flake8 --bug-report

{
  "platform": {
    "python_implementation": "CPython",
    "python_version": "3.10.7",
    "system": "Linux"
  },
  "plugins": [
    {
      "plugin": "mccabe",
      "version": "0.7.0"
    },
    {
      "plugin": "pycodestyle",
      "version": "2.10.0"
    },
    {
      "plugin": "pyflakes",
      "version": "3.0.1"
    }
  ],
  "version": "6.0.0"
}

describe the problem

what I expected to happen

I'm seeing developers using the file-level-noqa ignore wrongly from time to time, providing specific errors like # flake8: noqa: E712. What's confusing is that it gives the impression that it works as it doesn't throw that error anymore but the developers' understanding is incorrect (all errors are ignore). I understood that you don't want to support the file-level-specific-ignores but I think flake8 should do something to prevent this confusion.

See for instance https://til.codeinthehole.com/posts/filelevel-flake8-comments-ignore-all-errors/

My suggestion would be to detect that and throw an error? Somehow it is like providing a flake8 config with a wrong format

sample code

# flake8: noqa: E712

from os import *       # F401
assert True == True # E712

Let me know what you think, happy to work on this if you would welcome a PR

@asottile
Copy link
Member

given how much people were mad at 6.0 pointing out a common mistake I'm hesitant. I don't need another 2 weeks of needing to lock down the issue tracker while people scream at me in my email

@bagerard
Copy link
Contributor Author

bagerard commented Jan 29, 2023

I understand the hesitation then 😬. Thanks for the quick feedback and for your efforts in Python's ecosystem 🚀

@asottile
Copy link
Member

the "simplest" fix for this would be to slap a $ on the file regex

@sigmavirus24
Copy link
Member

I almost feel like there needs to be a "mode" for linting people's use of flake8. Like flake8 --warn-on-misuse that detects stuff like this so people could use that to prevent nonsense like this from creeping in. It would be forever a "beta" feature that adds new things to it. Could be used for deprecation warnings of upcoming breaking releases too. Sadly it'll only draw more ire because we don't just accept every feature request to make the tool less useful to large teams.

@jakkdl
Copy link

jakkdl commented Apr 30, 2023

@sigmavirus24 you can suggest it for https://github.com/PyCQA/flake8-bugbear

@LeXofLeviafan

This comment was marked as off-topic.

@Kolumbs

This comment was marked as off-topic.

@asottile
Copy link
Member

chatgpt is hot garbage

@PyCQA PyCQA locked as off-topic and limited conversation to collaborators Feb 12, 2024
@sigmavirus24
Copy link
Member

As a reminder to people saying "we should just do it" you are given software AS IS per the license. Unless you're maintaining the software, "just do it" isn't a justification. Please read https://blog.ian.stapletoncordas.co/2023/11/no-should-be-your-default before spewing that mentality around other projects

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

No branches or pull requests

6 participants