Pylint: Add support for noqa: ERROR MESSAGE

Created on 15 Sep 2018  ·  10Comments  ·  Source: PyCQA/pylint

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 bare noqa which I'm still against using in pylint). It could also help with the adoption as well with keeping your codebase linter agnostic if you plan to use just pylint and flake8.

Describe the solution you'd like

Support noqa: error message so noqa: no-member or noqa: E1101 in pylint.

enhancement

Most helpful comment

@edran I don't understand what you mean. Are you referring to add a pylint- or flake8- prefix to the error codes? That unfortunately doesn't seem like a big of change than the current situation where you'd use # pylint instead and it would probably be a larger discussion for the whole PyCQA org to find a common ground on the noqa support. What this current issue tries to accomplish is to allow folks that already use noqa to switch to pylint without too much hassle.

All 10 comments

Would it need some extra identifier in noqa: E1101 to indicate that we are about to ignore a pylint error and not error from some other tool? Is there really no overlap between pylint, pycodestyle, pydocstyle, flake8, others?

Also, would this work only per-line or also per-file/block (like # pylint: disable)?

@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 # pylint pragma, the new noqa will be just an alias of # pylint

FWIW I love this idea simply because # noqa: no-member is much shorter than # pylint: disable=no-member, so there are higher chances of easily fitting it after a line of code with a conservative line width limit.

Could you not add a namespace to differentiate between flake8 and pylint errors?

For instance instead of parsing the error codes directly, you could match codes that look like pylint-errorcode, so that you could then mix the errors at will.

I.e.:

# noqa: flake8error, pylint-error

@edran I don't understand what you mean. Are you referring to add a pylint- or flake8- prefix to the error codes? That unfortunately doesn't seem like a big of change than the current situation where you'd use # pylint instead and it would probably be a larger discussion for the whole PyCQA org to find a common ground on the noqa support. What this current issue tries to accomplish is to allow folks that already use noqa to switch to pylint without too much hassle.

👍+1

Upon further discussion, is does not seem possible for pylint to introduce #noqa support without breaking things in flake8, and making maintenance more difficult in the future for both projects. Therefore I'm closing this as something that we are unable to implement.

So, just how to use noqa and pylint: disable=xxxxx on the same line ?!

So, just how to use noqa and pylint: disable=xxxxx on the same line ?!

https://github.com/PyCQA/pylint/issues/2470#issuecomment-418255917

You can rewrite your comment something along the lines of # pylint: disable=; # noqa, this should make it work.

in my case

temp = 'long-text'  # pylint: disable=line-too-long # noqa: E501

@rachmadaniHaryono thanks for this hint!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

pylint-bot picture pylint-bot  ·  3Comments

jrial picture jrial  ·  3Comments

DevynCJohnson picture DevynCJohnson  ·  3Comments

GergelyKalmar picture GergelyKalmar  ·  3Comments

PCManticore picture PCManticore  ·  3Comments