Potential Namespace bug for stacked list comprehensions within class definitions

[JamesShipley]

Bug report

Bug description:

I think there is a bug relating to how list comprehensions are evaluated within class definitions on 3.11.5:

class C:
    P = [1, 2]
    
    Q = []
    # double `for` loop runs as expected
    for i in P:
        for j in P:
            Q.append(i * j)
    
    # same logic using a list comprehension results in a name error on the inner loop
    R = [
        i * j
        for i in P
        for j in P # name error here
    ]

This may be a duplicate of #127542, however I do not see why it should be seen as expected behaviour - it is slightly bizarre for such a simple list comprehension to be impossible within and only impossible within a class definition? This may be solved by PEP-709, but I am not sure.

CPython versions tested on:

3.11

Operating systems tested on:

No response

[terryjreedy]

Duplicate: in order to not 'leak' iteration names, the list comp is evaluated in a nested namespace. The output iterable is added to the namespace. Nested iterables are not, because in general they may depend on the outer iteration variable. Example where the inner iterable is the object is bound to the outer name: for row in array; for item in row: process item.