Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #19762
| Date | 2012-02-01 15:51 -0800 |
|---|---|
| From | Ethan Furman <ethan@stoneleaf.us> |
| Subject | Re: Question about name scope |
| References | (1 earlier) <mailman.5311.1328117874.27778.python-list@python.org> <jgc1cr$976$1@speranza.aioe.org> <CALwzidmBvCmeMOiSjOscuiTx7VXVmMvWkBU7hwQW5JDV85+N4A@mail.gmail.com> <4F29BB9C.70405@stoneleaf.us> <4F29C5E8.6000504@stoneleaf.us> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.5340.1328143879.27778.python-list@python.org> (permalink) |
Ethan Furman wrote:
> Ethan Furman wrote:
>> Ian Kelly wrote:
>>> I am not a dev, but I believe it works because assigning to locals()
>>> and assigning via exec are not the same thing. The problem with
>>> assigning to locals() is that you're fundamentally just setting a
>>> value in a dictionary, and even though it happens to be the locals
>>> dict for the stack frame, Python can't figure out that it should go
>>> and update the value of the optimized local to match. exec, on the
>>> other hand, compiles and executes an actual STORE_NAME operation. Of
>>> course, if the particular local variable hasn't been optimized by the
>>> compiler, then updating locals() works just fine (although you
>>> probably should not rely on this):
>>>
>>>>>> def f(x, y):
>>> ... locals()[x] = y
>>> ... print locals()[x]
>>> ... exec 'print ' + x
>>> ...
>>>>>> f('a', 42)
>>> 42
>>> 42
>>
>> Definitely should rely on it, because in CPython 3 exec does not
>> un-optimize the function and assigning to locals() will not actually
>> change the functions variables.
>
>
> Ouch, that should have been *not* rely on it; not because it doesn't
> work (exec uses locals() if one is not specified), but because it is
> easy for the names in the function to get out of sync with the names in
> the functions locals() (or __dict__).
I should stop answering now :( Ignore the __dict__ comment, it is
incorrect.
~Ethan~
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Question about name scope Olive <diolu@bigfoot.com> - 2012-02-01 18:11 +0100
Re: Question about name scope Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-01 09:21 -0800
Re: Question about name scope Ethan Furman <ethan@stoneleaf.us> - 2012-02-01 09:43 -0800
Re: Question about name scope Dave Angel <d@davea.name> - 2012-02-01 12:36 -0500
Re: Question about name scope Mel Wilson <mwilson@the-wire.com> - 2012-02-01 13:47 -0500
Re: Question about name scope Ian Kelly <ian.g.kelly@gmail.com> - 2012-02-01 14:49 -0700
Re: Question about name scope Ian Kelly <ian.g.kelly@gmail.com> - 2012-02-01 15:38 -0700
Re: Question about name scope Ethan Furman <ethan@stoneleaf.us> - 2012-02-01 14:24 -0800
Re: Question about name scope Ian Kelly <ian.g.kelly@gmail.com> - 2012-02-01 16:00 -0700
Re: Question about name scope Ethan Furman <ethan@stoneleaf.us> - 2012-02-01 15:08 -0800
Re: Question about name scope Ian Kelly <ian.g.kelly@gmail.com> - 2012-02-01 16:47 -0700
Re: Question about name scope Ethan Furman <ethan@stoneleaf.us> - 2012-02-01 14:53 -0800
Re: Question about name scope Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-02 00:34 +0000
Re: Question about name scope Ethan Furman <ethan@stoneleaf.us> - 2012-02-01 15:59 -0800
Re: Question about name scope Ethan Furman <ethan@stoneleaf.us> - 2012-02-01 15:41 -0800
Re: Question about name scope Ethan Furman <ethan@stoneleaf.us> - 2012-02-01 15:51 -0800
Re: Question about name scope Chris Rebert <clp2@rebertia.com> - 2012-02-01 09:38 -0800
Re: Question about name scope Christian Heimes <lists@cheimes.de> - 2012-02-01 18:50 +0100
csiph-web