Handle ComprehensionScope and their behaviour better

[DanielNoord]

• Add yourself to CONTRIBUTORS.txt if you are a new contributor.
• Write a good description on what the PR does.

Type of Changes

	Type
✓	🐛 Bug fix
✓	🔨 Refactoring

Description

Refactoring necessary for pylint-dev/astroid#1475 to be "acceptable" for pylint.

Note that the change to names_hint = ", ".join(names) might be unrelated, but I couldn't get pre-commit to pass without it and I wanted to show that if you clone pylint-dev/astroid#1475 and these changes then both test suites should pass.

[coveralls]

Pull Request Test Coverage Report for Build 1988874403

• 7 of 9 (77.78%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.01%) to 94.078%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
pylint/checkers/classes/special_methods_checker.py	1	2	50.0%
pylint/checkers/utils.py	1	2	50.0%

Totals
Change from base Build 1986048864:	-0.01%
Covered Lines:	15188
Relevant Lines:	16144

---

💛 - Coveralls

[DanielNoord]

@Pierre-Sassoulas I didn't expect this, but the tests seem to pass (with expected drop in coverage). If we can get confirmation on the approach taken in pylint-dev/astroid#1475 we can get this in 2.13.x as a hot fix and actually fix astroid's CI before merging the fix there 😄

[Pierre-Sassoulas]

I think we could merge directly for 2.13.0, after investigation of the coverage change ? Imo the code in pylint never considered that the comprehension scope could be something else than uninferrable because it never was, but this is not a voluntary design choice.

[DanielNoord]

I think we could merge directly for 2.13.0, after investigation of the coverage change ? Imo the code in pylint never considered that the comprehension scope could be something else than uninferrable because it never was, but this is not a voluntary design choice.

The coverage change is just two if statements for ComprehensionScope that will be covered when the change lands in astroid. So they are as expected.

[DanielNoord]

@Pierre-Sassoulas I have added some TODOs so that if for some unforeseen reason we don't merge the astroid PR we know why this is uncovered (and what we should do with it).