Terry J. Reedy <tjre...@udel.edu> added the comment:
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() ---------- resolution: -> not a bug stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue43481> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
