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 amaury.forgeotdarc, docs@python, eric.araujo, sdeibel, terry.reedy
Date 2012-02-25.00:18:05
SpamBayes Score 8.3709955e-07
Marked as misclassified No
Message-id <1330129086.92.0.703470700926.issue13557@psf.upfronthosting.co.za>
In-reply-to
Content
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
    print(incx())
History
Date User Action Args
2012-02-25 00:18:07terry.reedysetrecipients: + terry.reedy, sdeibel, amaury.forgeotdarc, eric.araujo, docs@python
2012-02-25 00:18:06terry.reedysetmessageid: <1330129086.92.0.703470700926.issue13557@psf.upfronthosting.co.za>
2012-02-25 00:18:06terry.reedylinkissue13557 messages
2012-02-25 00:18:05terry.reedycreate