-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Support # noqa: ...
pragmas
#3221
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, would it be worth splitting out the NoQA bits into a library that both Flake8 and PyLint can share so that we're not at odds with each other at any point? cc @asottile |
this patch is already problematic afaict -- |
it would also all-but-ruin my plan of making |
@asottile Yeah, we already use our own pragma but the idea for this enhancement started from the fact that all the static analysis tools use their own pragma structure. We'd like folks to be able to use I also agree with @sigmavirus24 that it would be great to split the common bits in a library if we decide to go this route. |
yeah I'd rather pylint not use flake8's maybe a new pragma that we can all share? though it'll have the same drawbacks and (imo) not really much advantages (since you can't get |
I'm on board with having a common library as well. The strict noqa problem suffers the same issue. How can we know all the valid error codes? I don't think it's possible. |
So I think this becomes really annoying if we have to specify things: |
The consensus seem to be that at this point |
I agree with this as well. |
So, just how to use |
I assume this works: # noqa: ... # pylint:disable=... |
|
pydocstyle, pycodestyle, and other tools that support |
Steps
doc/whatsnew/<current release.rst>
.Description
Added support for understanding
# noqa: ...
pragmas. Bare# noqa
pragmas are not supported.Cc @sigmavirus24 who may be interested in this change. Also we've added support for parsing symbolic message IDs (eg
no-member
instead ofE1101
) but this would mean that flake8 cannot parse other messages in that same pragma (Seedoc/user_guide/message-control.rst
). I don't know if you think it's worth making a change in flake8 to parse and ignore those types of IDs before we merge this?There was also discussion on the original issue about whether we should be namespacing message IDs in pragmas to avoid conflicts.
Type of Changes
Related Issue
Closes #2493