N816 considers generator/list comprehensions to be globally scoped

[ember91]

The following will trigger N816 twice:

(someVar1 == 8 for someVar1 in [])
[someVar2 == 8 for someVar2 in []]

N816 is explained as "mixedCase variable in global scope".

But are they really globals? Should there not be a new error code Nxyz for this? Or is it a limitation or shortcut in pep8-naming that leads to this behavior?

Version: 0.14.1

[sigmavirus24]

So on some versions of Python (I think this was fixed ~recently) leaked the variable from the list comprehension outside of the comprehension. That may no longer be correct, but if your example is what you're checking, you would (on those versions) be leaking someVar1 or someVar2 into the global context.

[ember91]

I tested this with Python 3.11.5.

But which rule is supposed to catch this then if not N816?

[sigmavirus24]

It would be N816 but I suspect we need to put a version cap on that , I just can't remember when the language changed such that comprehension bindings weren't leaked

[sigmavirus24]

I suspect we could eliminate this behavior of the check since we no longer support the buggy versions of Python https://stackoverflow.com/a/29907448

[ember91]

I'm a bit lost here. Eliminate what behavior of the check? That it identifies mixed case variables in comprehensions?

[dhruvmanila]

So on some versions of Python (I think this was fixed ~recently) leaked the variable from the list comprehension outside of the comprehension. That may no longer be correct, but if your example is what you're checking, you would (on those versions) be leaking someVar1 or someVar2 into the global context.

Can you say more about this? I'm not sure if this was ever the case unless it's a named assignment (x := 1) which is a special case that's mentioned in the PEP as well.

[ember91]

Any more input here? @sigmavirus24 @dhruvmanila