Showing content from http://mail.python.org/pipermail/python-dev/attachments/20100526/0c536c93/attachment-0001.html below:
<br><br><div class="gmail_quote">On Wed, May 26, 2010 at 11:48, Mark Dickinson <span dir="ltr"><<a href="mailto:dickinsm@gmail.com">dickinsm@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, May 26, 2010 at 10:15 AM, Colin H <<a href="mailto:hawkett@gmail.com">hawkett@gmail.com</a>> wrote:<br>
> Â issue991196 was closed being described as intentional. Â I've added<br>
> a comment in that issue which argues that this is a serious bug (also<br>
> aserted by a previous commenter - Armin Rigo), because it creates a<br>
> unique, undocumented, oddly behaving scope that doesn't apply closures<br>
> correctly. At the very least I think this should be acknowledged as a<br>
> plain old bug (rather than a feature), and then a discussion about<br>
> whether it will be fixed or not.<br>
<br>
</div>Here's a quick recap of the issue so that people don't have to go<br>
searching through the bug archive. Â In Python 2.x, we get the<br>
following behaviour:<br>
<br>
>>> code = """\<br>
... y = 3<br>
... def f():<br>
... Â Â return y<br>
... f()<br>
... """<br>
>>> exec code in {} Â # works fine<br>
>>> exec code in {}, {} Â # dies with a NameError<br>
Traceback (most recent call last):<br>
 File "<stdin>", line 1, in <module><br>
 File "<string>", line 4, in <module><br>
 File "<string>", line 3, in f<br>
NameError: global name 'y' is not defined<br>
<br>
The issue is whether the second example should work, given that two<br>
different dictionaries have been passed.<br>
<br>
The cause of the NameError can be seen by looking at the bytecode: y<br>
is bound using STORE_NAME, which stores y into the locals dictionary<br>
(which here is *not* the same as the globals dictionary) but the<br>
attempt to retrieve the value of y uses LOAD_GLOBAL, which only looks<br>
in the globals.<br>
<br>
>>> co = compile(code, 'mycode', 'exec')<br>
>>> dis.dis(co)<br>
 1      0 LOAD_CONST        0 (3)<br>
       3 STORE_NAME        0 (y)<br>
<br>
 2      6 LOAD_CONST        1 (<code object f at<br>
0xa22b40, file "mycode", line 2>)<br>
       9 MAKE_FUNCTION       0<br>
      12 STORE_NAME        1 (f)<br>
<br>
 4      15 LOAD_NAME         1 (f)<br>
      18 CALL_FUNCTION       0<br>
      21 POP_TOP<br>
      22 LOAD_CONST        2 (None)<br>
      25 RETURN_VALUE<br>
>>> dis.dis(co.co_consts[1]) Â # disassembly of 'f'<br>
 3      0 LOAD_GLOBAL        0 (y)<br>
       3 RETURN_VALUE<br>
<br>
This is a long way from my area of expertise (I'm commenting here<br>
because it was me who sent Colin here in the first place), and it's<br>
not clear to me whether this is a bug, and if it is a bug, how it<br>
could be resolved. Â What would the impact be of having the compiler<br>
produce 'LOAD_NAME' rather than 'LOAD_GLOBAL' here?</blockquote><div><br></div><div>It wouldn't matter. The 'f' function only knows about its own namespace (separate from the surrounding code's local namespace), and the global namespace. LOAD_NAME is only different from LOAD_GLOBAL in that it looks in the local namespace first, but in this case the local namespace contains nothing. Here's what happens:</div>
<div><br></div><div>'exec code in d1, d2' executes code with 'd1' as locals and 'd2' as globals. Assignment always operates on the local namespace (barring the 'global' declaration.) The function definition also assigns to the local namespace, but the created function knows nothing about that local namespace -- it only cares about its own namespace and the global namespace, 'd1'.</div>
<div><br></div><div>'exec code in d1' does the same thing as 'exec code in d1, d1': it uses the same dict for the locals and the globals. The execution of the code doesn't change -- the assignment to 'y' still assigns to the locals, and the 'f' function still looks it up in globals, but now *they are the same dict*. Using the same dict for locals and globals is how modules work, as well.</div>
<div><br></div><div>The main confusion here is the fact that 'exec' doesn't generate closures. (Nobody was ever confused about this behaviour back in Python 2.0-and-earlier! :-) The reason for that is the disconnect between the compiler and the exec statement: the compiler sees no enclosing function, so it doesn't generate a closure. The exec statement, because it gets two different namespaces, then executes it like a function, with a distinct local namespace.</div>
<div><br></div></div>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org">thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!<br>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4