-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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 an option to disable a message on the next line so a line does not become too long because of a disable #1682
Comments
We are already stripping the pragma for each line before checking for Which pylint version are you using? Can you add a minimal test case for which I can reproduce this? |
Just tested here on a new virtualenv.
The trailing pragma does trigger a "line too long" error, but from flake8, not from pylint. I guess I got confused, the other day. My apologies. Trying to silence flake8, this data = self._wrapper_class(data) # pylint: disable=not-callable # noqa triggers the This: data = self._wrapper_class(data) # pylint: disable=not-callable noqa triggers line too long from flake8. This yields no error: data = self._wrapper_class(data) # noqa # pylint: disable=not-callable
# or even shorter
data = self._wrapper_class(data) # noqa pylint: disable=not-callable Is this the recommended approach? I think the cons are that
I realize that this is not a pylint issue as I thought but rather a pylint/flake8 issue. Anyway, let alone flake8, it is a pity that pylint, while enforcing coding style, generates exceptions to its own rules. Even if it auto-ignores its pragmas while enforcing the From this perspective, I still think a pragma that would disable a rule for the next line would be nice. I won't argue about it, though, because I don't know pylint's code architecture and this might be a huge breaking change for little benefit. Besides, I'm not an experienced pylint user, so my vision might be biased towards my use case. I'm also interested in knowing which alternative has consensus among the community. Should I be writing it like this ? data = self._wrapper_class(data) # noqa pylint: disable=not-callable Feel free to redirect me to stackoverflow if I'm abusing the bugtracker for what looks more like a question. |
I have run into the same issue and am interested in a solution, and I found how to improve the previously listed solutions by disabling just the line too long issue for flake8:
|
IMO stripping the pragma before checking line length defeats the purpose of |
Hello, ESLint has disable-next-line for instance |
This seems like a basic feature and pretty integral to anybody using any kind of linter (eg. black for spacing and styling). |
@dave-labscubed thanks for your pertinent remark. Do not hesitate to make a PR to see this basic feature implemented. |
Adding `# pylint: disable-next=msgid` to your file will disable the message for the next line. This closes pylint-dev#1682
* Add ``disable-next`` option Adding `# pylint: disable-next=msgid` to your file will disable the message for the next line. This closes #1682 * Add documentation, rorganize the FAQ for disable/enable and add ref to the full doc Co-authored-by: Pierre Sassoulas <pierre.sassoulas@gmail.com>
Follow up for taking disable-param in the line length into account is here: #4802 |
Hi. I'm trying to ignore a pylint error for a single line and I don't know how it should be done.
Example use case:
The
data = ...
line triggers anot-callable
error I would like to mask.I'm not sure how to do that.
This triggers a
line-too-long
error, unless I also disableline-too-long
in the line, which makes it even longer (in my real-life use case, data is a longer word and the line is more than 80 characters):This disables the warning for the whole
if
context:This is functionally correct but a bit too verbose:
This was discussed a while ago on a mailing-list thread.
I guess this is bound to happen as long as the only way to disable a warning for a single line is to add a trailing pragma, especially since pylint supports disable by (long) name rather than (short) code.
Wouldn't it be handy to have some sort of ignore-for-next-statement pragma?
The text was updated successfully, but these errors were encountered: