This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients chrisgmorton, terry.reedy
Date 2021-03-20.20:29:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1616272163.17.0.162989690168.issue43481@roundup.psfhosted.org>
In-reply-to
Content
Foolish me. Commenting out the first exec results in the 2nd exec raising.  Commenting out the 2nd exec also results in the class code raising, which is what I expected.  The point of the class code is to partially explain the exception, which is not a bug, but a consequence of passing separate global and initial local namespaces, combined with comprehensions being executed, starting in 3.0, in a new local namespace, separate from the one you passed in.

The exec doc in https://docs.python.org/3/library/functions.html#exec explains the effect of passing different global and local namespaces with "If exec gets two separate objects as globals and locals, the code will be executed as if it were embedded in a class definition."  There is no class, but this is the only way to get the same effect in Python code (without exec/eval).

The NameError has nothing to do with subscripting as it happens upon the attempt to load c.  Remove the subscription and the exception it remains.  Instead, it arises because in 3.x, but not in 2.x, comprehensions are executed in a separate local namespace, the same as a method, where the passed in local namespace is invisible.

Here are simpler examples that both raise NameError.

exec("c=1\nlist(c for i in [1])", globals(), {})
----

class A:
    c =1
    def f(self): c

A().f()
History
Date User Action Args
2021-03-20 20:29:23terry.reedysetrecipients: + terry.reedy, chrisgmorton
2021-03-20 20:29:23terry.reedysetmessageid: <1616272163.17.0.162989690168.issue43481@roundup.psfhosted.org>
2021-03-20 20:29:23terry.reedylinkissue43481 messages
2021-03-20 20:29:23terry.reedycreate