Python3 exec locals - this must be a FAQ
davea at davea.name
Tue Feb 12 16:40:18 CET 2013
On 02/12/2013 09:29 AM, Helmut Jarausch wrote:
> On Tue, 12 Feb 2013 08:27:41 -0500, Dave Angel wrote:
>> On 02/12/2013 06:46 AM, Helmut Jarausch wrote:
>>> I've tried but didn't find an answer on the net.
>>> The exec function in Python modifies a copy of locals() only.
>>> How can I transfer changes in that local copy to the locals of my
>>> function ** without ** knowing the names of these variables.
>>> E.g. I have a lot of local names.
>>> _locals= locals()
>> This doesn't copy everything. But perhaps you know that and you're just
>> testing us.
> No, I didn't know. And I'm bit surprised since this is recommend
> several times, e.g. in "Python Essential Reference, 4th ed" by
> David Beazley.
That assignment is useful, because it presumably saves the time that
calling locals() will take constructing the dict. But copying anything
by assignment just makes a new reference to the same thing. If that
thing is mutable, as a dict is, then changes made to the (dict) object
are visible to both.
>>> expr=compile(input('statements assigning to some local variables '),
>>> 'user input','exec')
>>> How can I "copy" the new values within _locals to my current locals.
>>> If I knew that Var1 has changed I could say Var1 = _locals['Var1']
>>> but what to do in general?
>> locals()["Var1"] = _locals["Var1"] will set the same Var1 local.
> Thanks for this hint which surprises me again since I thought
> locals() by itself is a copy only.
(Thanks MRAB for your correction.)
As MRAB points out, I was in error on this point. I only tested it in
global scope. Inside a function it doesn't seem to work. See docs below.
>> So you might write a loop on _locals.
>> But beware if someone has deleted one of the "variables" it may not do
>> what you'd like. You cannot necessarily add back a local with the above
> Does this mean that adding something completely new won't work?
> Many thanks,
That depends. All I can say for sure is it won't work for CPython to
create new local variables inside a function that way. It seems to work
for globals (which are also locals when code of global scope is using
it), but I wouldn't count on it.
Note the sentence:
"""The contents of this dictionary should not be modified; changes may
not affect the values of local and free variables used by the interpreter"""
Notice that adding or removing items from a dictionary is modifying it,
while changing values that the keys are associated with is not. But
apparently the documentation meant it more strictly than it was worded.
If you really have dozens of "variables" that you want to pass to exec,
then restore their original values after it returns, I suggest you make
your own (empty) class, and use that as a namespace to accomplish it.
The reason I was tripped up on this definition is that I've concluded
long ago that messing with locals() is a losing game, so I'd forgotten
some of the subtlety.
If we knew what the real problem was, we might have a suggestion. For
example, if the intent is for the exec to work with a copy of the
variables, without affecting the originals, then why not use the copy
module, and pass the *copy* to the exec logic.
More information about the Python-list