Suggestion to improve redefined-outer-name or to introduce a new rule

[Lucas-C]

Current problem

The following code may not print what you expect on the last line:

from collections import defaultdict
errors = [
    Exception("E101", "Boom!"),
    Exception("E101", "Bam!"),
    Exception("E102", "Shazam!"),
]
errors_per_arg0 = defaultdict(list)
for error in errors:
    errors_per_arg0[error.args[0]].append(error)
for arg0, errors in errors_per_arg0.items():
    print(arg0, "count:", len(errors))
print(errors)

The issue comes from the for loop, where the errors loop variable shadows the previously defined list.

The unexpected problem is that, on the last line, errors is now a 1-item list!
There is this script output:

E101 count: 2
E102 count: 1
[Exception('E102', 'Shazam!')]

As far as I know, Pylint currently does not have any rule that detects this (tested using Pylint 2.17.3 & 3.0.0a6).
redefined-outer-name for example, does not get triggered.

Desired solution

First, I'd like to know what Pylint maintainers think to be the best approach:

• improve the existing redefined-outer-name to cover this
• introduce a new rule to detect this case

Additional context

There are some edge cases to consider when such case happens, where the definition of loop variable "erases" a variable in the current scope:

• if this variable is not used after the loop, should an error be raised?
• if this variable is re-assigned after the loop, before being read, should an error be raised?

[Lucas-C]

Related issues & PRs:

• redefined-outer-name no longer emitted in nested loops #6803
• [optional ext] Emit redefined-loop-name for redefinitions of loop variables in body #5649

Note that pylint --load-plugins=pylint.extensions.redefined_loop_name ./issue_repro.py does not raise any error on the code sample provided in this issue description (tested using Pylint 2.17.3 & 3.0.0a6).

[jacobtylerwalls]

This one's tough! We'd need to distinguish this from the general case where reassigning a variable (for clarity?) is perfectly fine.

x = apple or banana
x = x or candy

Do you have an idea about what would distinguish these cases?

[jacobtylerwalls]

Wasn't meaning to be dense. I take it the idea is that defining loop variables are special. Just wondering your thoughts.

[Lucas-C]

Wasn't meaning to be dense. I take it the idea is that defining loop variables are special. Just wondering your thoughts.

I opened #8663 as a starting point to explore how this could be implemented.

What do you think of the approach taken there?

[jacobtylerwalls]

I like it! Sorry for the delay in reviewing, we'd really like to get a report from the primer tool, and I haven't debugged why it's not working on your branch. I can fire it up locally on just a subset of packages if need be.

[Lucas-C]

I like it! Sorry for the delay in reviewing, we'd really like to get a report from the primer tool, and I haven't debugged why it's not working on your branch. I can fire it up locally on just a subset of packages if need be.

Thank you for the feedback 😊
Alright, no worry.
Can I do anything to help?