gh-121377: Fix closure with intervening comprehension

[carljm]

Fix the case where a comprehension iteration variable is inlined into a function that otherwise does not have a variable by that name, but the name should be a free variable from an enclosing scope passed through to other enclosed scopes.

• Issue: Wrong binding of closure variable with intervening list comprehension #121377

[JelleZijlstra]

Found this failure case:

>>> def f(x):
...     def g():
...         [(x, lambda: x) for x in []]
...         def h():
...             print(x)
...         h()
...     g()
...     
>>> f(1)
Traceback (most recent call last):
  File "<python-input-1>", line 1, in <module>
    f(1)
    ~^^^
  File "<python-input-0>", line 7, in f
    g()
    ~^^
  File "<python-input-0>", line 6, in g
    h()
    ~^^
  File "<python-input-0>", line 5, in h
    print(x)
          ^
NameError: cannot access free variable 'x' where it is not associated with a value in enclosing scope

[JelleZijlstra]

Simpler repro:

def f(x):
    def g():
        [lambda: x for x in []]
        def h():
            assert x == 1
        h()
    g()
    
f(1)

[JelleZijlstra]

Suggested change

	[lambda: x for x in [1]]
	[lambda: x for x in [2]]

As discussed:

• Use a different value (the test ran correctly but used the wrong 1)
• Should change it to execute the lambda so we ensure the value of x inside the lambda is right

[limwz01]

@carljm I think the tests are not testing the exact situation in my original example. They already pass in Python 3.13. The intervening list comprehension needs to be in the innermost scope like my original example, which still fails.

[limwz01]

oh, sorry ignore me, I was confused. apparently the tests passed because I ran it at module scope. they are also tested in function scope, so that is ok, I think

[limwz01]

but maybe you should also add a test to also test a local in f() to be sure. (I keep getting confused by the change of the function names between our examples)