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.

Title: exec of list comprehension fails on NameError
Type: behavior Stage: resolved
Components: Documentation Versions: Python 3.2, Python 3.3, Python 2.7
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: docs@python Nosy List: Trundle, amaury.forgeotdarc, daniel.urban, docs@python, eric.araujo, flox, jonathan.hartley, josmiley, michael.foord, mjs0, python-dev, rhettinger, sdeibel, terry.reedy, westley.martinez
Priority: normal Keywords: easy, patch

Created on 2011-12-08 20:25 by sdeibel, last changed 2022-04-11 14:57 by admin. This issue is now closed.

File name Uploaded Description Edit sdeibel, 2011-12-08 20:25 Illustrates the bug
exec-eval-clarification.diff sdeibel, 2011-12-12 21:24 Attempt at clarifying the docs review
Messages (9)
msg149050 - (view) Author: Stephan R.A. Deibel (sdeibel) Date: 2011-12-08 20:25
Calling exec() on code that includes a list comprehension that references a defined local variable x fails incorrectly on "NameError: global name 'x' not defined".
msg149096 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2011-12-09 14:10
This is expected and documented:
"Free variables are not resolved in the nearest enclosing namespace, but in the global namespace.", a free variable being a variable "used in a code block but not defined there".
And yes, a list comprehension defines a code block.

Try using exec(code, locals()). It's a good habit anyway to always pass a namespace to exec().
msg149100 - (view) Author: Stephan R.A. Deibel (sdeibel) Date: 2011-12-09 14:20
Ah, thanks, there it is... I thought this must be dealt with somewhere but couldn't find it.  Maybe should add something to the 'exec' statement docs to reference this (from a usability-of-docs standpoint).

BTW, my code already sends the namespaces to exec (from current stack frame; it's part of a debugger) and probably would break other cases to alter this.

Well, anyway, sorry for the invalid bug report...
msg149168 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-12-10 16:32
Would you like to make a doc patch?
msg149357 - (view) Author: Stephan R.A. Deibel (sdeibel) Date: 2011-12-12 21:24
Here's a patch to the docs that notes the issue and refers the reader to the relevant execution model docs page.  I have also attempted to clarify the "interaction with dynamic features" section of the execution model page.
msg154174 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2012-02-25 00:18
Issues like this, about exec, have come up multiple times. I just closed #14049 as a duplicate of this, and listed there some other issues. So I think that the doc for exec (and execfile in 2.7) could be better still. I would like to see something like the following added, whether instead of or in addition to the current proposal -- perhaps after "If provided, locals can be any mapping object." (quote from the 3.2 exec entry)

"At module level, globals and locals are the same dictionary. If one passes two separate objects as globals and locals, the code will be executed as if it were embedded in a class definition."

To me, this is friendlier and less intimidating than 'free variable' and the Execution model doc chapter. It summarizes the essential problem with such exec calls.

To illustrate, the following gives the same NameError. and for the same reason, as exec(code,{},{}), where code is the quoted unindented version with the class line deleted.

class x:
    x = 1
    def incx():
        return x+1
msg154180 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-02-25 05:30
Stefan: This fell off my radar, sorry I haven’t reviewed your patch yet.

Terry: +1
msg164873 - (view) Author: Florent Xicluna (flox) * (Python committer) Date: 2012-07-07 15:25
Issue #11796 marked as duplicate of this one.

However the issue described in #11796 does not involve exec/execfile.
It is about scopes for list comprehension like this one.

Another doc patch should probably be written to cover the case described in #11796 too.
msg165039 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2012-07-08 21:53
New changeset ab22ffa6fb2e by Terry Jan Reedy in branch '2.7':
Issue #13557: Clarify effect of giving two different namespaces to exec or

New changeset ea670d71a36d by Terry Jan Reedy in branch '3.2':
Issue #13557: Clarify effect of giving two different namespaces to exec or

New changeset b47ae7a9e685 by Terry Jan Reedy in branch 'default':
Merge 3.2 closes issue 13557
Date User Action Args
2022-04-11 14:57:24adminsetgithub: 57766
2012-11-25 18:03:32mark.dickinsonlinkissue8824 superseder
2012-07-08 21:53:49python-devsetstatus: open -> closed

nosy: + python-dev
messages: + msg165039

resolution: fixed
stage: needs patch -> resolved
2012-07-07 15:25:42floxsetmessages: + msg164873
2012-07-07 15:21:17floxsetnosy: + rhettinger, michael.foord, Trundle, jonathan.hartley, flox, daniel.urban, westley.martinez, mjs0, josmiley
2012-07-07 15:20:51floxlinkissue11796 superseder
2012-02-25 05:30:18eric.araujosetmessages: + msg154180
2012-02-25 00:18:06terry.reedysetnosy: + terry.reedy

messages: + msg154174
versions: + Python 2.7, Python 3.2
2012-02-25 00:15:24terry.reedylinkissue14049 superseder
2011-12-12 21:24:52sdeibelsetfiles: + exec-eval-clarification.diff
keywords: + patch
messages: + msg149357

versions: - Python 2.7, Python 3.2
2011-12-10 16:32:41eric.araujosetassignee: docs@python
components: + Documentation
versions: + Python 2.7, Python 3.3
keywords: + easy
nosy: + docs@python, eric.araujo

messages: + msg149168
resolution: not a bug -> (no value)
stage: needs patch
2011-12-09 14:20:53sdeibelsetstatus: pending -> open

messages: + msg149100
2011-12-09 14:10:58amaury.forgeotdarcsetstatus: open -> pending

nosy: + amaury.forgeotdarc
messages: + msg149096

resolution: not a bug
2011-12-08 20:25:54sdeibelcreate