-
-
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
Add support for noqa: ERROR MESSAGE #2493
Comments
Would it need some extra identifier in Also, would this work only per-line or also per-file/block (like |
@tuukkamustonen We probably won't need to indicate that we're ignoring a pylint or say a flake8 error. We can recognise our errors and hopefully other tools don't have an overlap with ours but with a different meaning (e.g. E1101 to have a separate meaning in pylint vs flake8) The plan here is to help onboard folks on using pylint, if they don't have to change the pragmas just for its sake. Regarding the scoping of the pragma, it will work as the current |
FWIW I love this idea simply because |
Could you not add a namespace to differentiate between For instance instead of parsing the error codes directly, you could match codes that look like I.e.:
|
@edran I don't understand what you mean. Are you referring to add a |
👍+1 |
Upon further discussion, is does not seem possible for pylint to introduce |
So, just how to use noqa and pylint: disable=xxxxx on the same line ?! |
in my case temp = 'long-text' # pylint: disable=line-too-long # noqa: E501 |
@rachmadaniHaryono thanks for this hint! |
@rachmadaniHaryono : Sooo... if a line is too long, your advice is to append 46 chars of unreadable boilerplate comments, which have to be written just the right way? |
Current best solution is to do: # pylint: disable-next=line-too-long
temp = 'long-text' # noqa: E501 noqa is not specific to flake8, in particular since ruff uses it too. The discussion that went on in #3221 is now outdated. Reopening for discussions / specifications. I think that this would be confusing: temp = 'long-text' # noqa: E501,line-too-long But pylint not raising in this case would make sense: temp = 'long-text' # noqa Maybe even in this case: temp = 'long-text' # noqa: E501 |
Is it really that hard, to respect all the It's just super annoying if e.g. your IDE wants one style of marking issues, and pylint another one. |
@ml31415 There is no clear 1:1 mapping from flake8 IDs to pylint messages. Someone would need to create a mapping between all the ones considered equivalent (and that needs to be kept up to date). Things are always "not that hard" when you're not the person actually doing the work 😉 |
@The-Compiler it doesn't need to be perfect. Even ignoring any message for the line, when there is # noqa in there would already be helpful. |
I re-read the description of the issues and I understand why PCManticore was against raw
Maintaining an (up to date) list of equivalent message in other tool is another issue, I've opened #8579 to follow-up. |
@Pierre-Sassoulas option 1 doesn't need to be default behaviour. It would totally be sufficient, if this behaviour is hidden behind a command line flag. This poll is well intended, but such a command line flag |
Yeah my bad, you're right that this survey is useless, everyone reading is interested by this issue and is going to vote to fix it. Also the interest in I like the idea of adding an option for pylint/pylint/utils/pragma_parser.py Lines 14 to 25 in 4a485e2
We could start to be stricter in what we consider a good disable, for example by being exactly as strict as flake8 / ruff in order to simplify this. It's breaking change season after all. It might also be a good time to remove the very old pylint/pylint/utils/pragma_parser.py Line 37 in 4a485e2
|
I would also like support for |
Is your feature request related to a problem? Please describe
Yes. The problem is that every linter out there has its own pragma control, leading to a mess if you want to support bandit, pylint, pyflakes, flake8, mypy:
… # type: … # noqa: E501 # pylint: disable=line-too-long # nosec
I think it would help if we'd also support
noqa
with an error message (not barenoqa
which I'm still against using inpylint
). It could also help with the adoption as well with keeping your codebase linter agnostic if you plan to use justpylint
andflake8
.Describe the solution you'd like
Support
noqa: error message
sonoqa: no-member
ornoqa: E1101
inpylint
.The text was updated successfully, but these errors were encountered: