Add disable-next option

[DanielNoord]

• Add yourself to CONTRIBUTORS if you are a new contributor.
• Add a ChangeLog entry describing what your PR does.
• If it's a new feature, or an important bug fix, add a What's New entry in
  doc/whatsnew/<current release.rst>.
• Write a good description on what the PR does.

Type of Changes

	Type
✓	✨ New feature

Description

Adding # pylint: disable-next=msgid to your file will disable the message for the next line.
Similar to how many linter and checkers do this.
This closes #1682

[DanielNoord]

#1682 also discusses another issue about disabling line-too-long and whether disable messages should count towards line length. This is not covered by this PR but I think warrants a different issue, as the feature requested in the OP of the issue is implemented here.

[DanielNoord]

I think the failing tests are due to changes to the Python 3.10 runner. Probably related to the release of RC1 on Monday. The tests on the main branch were passing yesterday, but when I merged main into my own repo this morning they failed. See here.
Probably need to add an .rc file to the failing tests. The CodeQL failures are new to me. Should we do something with them?

[Pierre-Sassoulas]

I think the failing tests are due to changes to the Python 3.10 runner.

Definitely, we can also see it in #4777

Regarding code QL, I dismissed them, there's no secret here, it's just a variable name in a functional test.

I think this solve the issue with line too long, we have a way to disable only one line when the line is long. thanks a lot for the implementation 👍

[DanielNoord]

I doesn't fully solve this comment though. Which got quite a bit of thumb-up's. So perhaps we need to keep it open/make a new issue?

[Pierre-Sassoulas]

I doesn't fully solve this comment though.

I understand this comment as not counting the # disable=line-too-long in the line length defeat the purpose of line-too-long because the ling is even longer than before. And I agree with this, we should not do it. I think this disable-next is the perfect solution :)

[DanielNoord]

I don't fully agree. I think the comment that we shouldn't cut off the disable-param when calculating the line-length is valid.
If a user has set their screen width to fit a certain number of columns they should be able to see all code, including any comments and disable-param. This PR gives users the ability to move these disable-params to the line above, but I think we should indeed raise an (optional) message whenever line + comments > max line width. That does not fit within this PR, but that request is included in #1682.

[Pierre-Sassoulas]

Ok it makes sense, what about creating another issue for a checker for code + comment > max char ?

[Pierre-Sassoulas]

We need a little example in the documentation (FAQ and message control chapter). This is a pretty important feature, and I think it need to be visible :)

[coveralls]

Coverage decreased (-0.004%) to 92.586% when pulling 602a596 on DanielNoord:disable-improvements into 8ea16d4 on PyCQA:main.

[DanielNoord]

Not the best documentation writer. Please add whatever you deem necessary!

[Pierre-Sassoulas]

No no, it was perfect, thank you 😄

[lafrech]

Original poster of #1682, here. Thank you guys for this feature.