Make disable-next only consider the succeeding line

[DanielNoord]

• Write a good description on what the PR does.
• Create a news fragment with towncrier create <IssueNumber>.<type> which will be
  included in the changelog. <type> can be one of: new_check, removed_check, extension,
  false_positive, false_negative, bugfix, other, internal. If necessary you can write
  details or offer examples on how the new change is supposed to work.
• If you used multiple emails or multiple names when contributing, add your mails
  and preferred name in script/.contributors_aliases.json

Type of Changes

	Type
✓	🐛 Bug fix

Description

Closes #7401

[coveralls]

Pull Request Test Coverage Report for Build 2991830942

• 16 of 16 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.001%) to 95.333%

---

Totals
Change from base Build 2989383939:	0.001%
Covered Lines:	16995
Relevant Lines:	17827

---

💛 - Coveralls

[Pierre-Sassoulas]

👌

[DanielNoord]

Is this an acceptable change in behaviour? I think it is. This seems to be an unintended side effect of checking for block lines that we didn't consider previously.

[Pierre-Sassoulas]

Is there a way to make disable-next work on the whole if like before ? I think it's going to be reported as a regression, having to change disables when upgrading pylint does not feel great.

[DanielNoord]

Not if we also don't want to have the issue reported in the OP. I think it makes sense for disable-next only to work for the next line and I think this is a relatively minor change to have to fix in an auto-update. Obviously it is annoying but let's fix this now while the impact is still relatively minor (compared to a 10 year long supported behaviour).

[Pierre-Sassoulas]

Fair enough !

[github-actions]

🤖 According to the primer, this change has no effect on the checked open source code. 🤖🎉

This comment was generated for commit bf917df