classification
Title: An inconsistency with nested scopes
Type: behavior Stage:
Components: Interpreter Core Versions: Python 2.6
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: jhylton Nosy List: ajaksu2, arigo, georg.brandl, hawkett, jhylton, josiahcarlson, mark.dickinson, nickjacobson
Priority: normal Keywords:

Created on 2004-07-14 21:30 by nickjacobson, last changed 2010-05-26 11:40 by mark.dickinson. This issue is now closed.

Files
File name Uploaded Description Edit
python1.py nickjacobson, 2004-07-14 21:30 Nested scope of y fails, and it shouldn't.
Messages (8)
msg21611 - (view) Author: Nick Jacobson (nickjacobson) Date: 2004-07-14 21:30
There's an inconsistency with nested scopes.

From the Python Ref. Manual:

"If [a local variable] definition occurs in a function block, 
the scope extends to any blocks contained within the 
defining one..."

i.e. So as long as code is not on the module level, 
scopes are extended.  Therefore this works:

def main():
	y = 3
	def execfunc():
		print y
	execfunc()

if __name__ == '__main__':
	main()

In addition, if code IS on the module level, its variables 
go in globals().  So this works too:

y = 3
def execfunc():
	print y
execfunc()

However, (here's the inconsistency) the following code 
fails, saying that y is undefined:

def main():
	s = \
"""
y = 3
def execfunc():
	print y
execfunc()
"""
	d = {}
	e = {}
	exec s in d, e

if __name__ == '__main__':
	main()

In this case, the code in s is treated like it's on the 
module level, and the nested scope treatment of y 
doesn't occur.  BUT, unlike normal code on the module 
level, y doesn't go in globals().  I think globals() is 
locked or something?


Conclusion:

The latter piece of code should work; that is, y should 
be nested and therefore recognized by execfunc().
msg21612 - (view) Author: Josiah Carlson (josiahcarlson) * Date: 2004-07-22 16:55
Logged In: YES 
user_id=341410

>>> def f():
...     y = 5
...     print 'y' in globals(), 'y' in locals()
...     def i():
...         print 'y' in globals(), 'y' in locals()
...     i()
...
>>> f()
False True
False False
>>>
>>> def g():
...     gl = {};lo={}
...     exec '''y = 5
... print 'y' in globals(), 'y' in locals()
... def i():
...     print 'y' in globals(), 'y' in locals()
... i()
... ''' in gl, lo
...
>>> g()
False True
False False

That looks constant...but what if we print out 'y'?

>>> def s():
...     y = 5
...     print 'y' in globals(), 'y' in locals(), y
...     def i():
...         print 'y' in globals(), 'y' in locals(), y
...     i()
...
>>> s()
False True 5
False True 5
>>>
>>> def t():
...     gl = {};lo = {}
...     exec '''y = 5
... print 'y' in globals(), 'y' in locals(), y
... def i():
...     print 'y' in globals(), 'y' in locals(), y
... i()
... ''' in gl, lo
...
>>> t()
False True 5
False False
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 3, in t
  File "<string>", line 5, in ?
  File "<string>", line 4, in i
NameError: global name 'y' is not defined

Now why did 'y' stick itself into the locals() of i() in
s()?  Is this another bug?

What if we remove the namespaces gl and lo?

>>> def u():
...     exec '''y = 5
... print 'y' in globals(), 'y' in locals(), y
... def i():
...     print 'y' in globals(), 'y' in locals(), y
... i()
... '''
...
>>> u()
False True 5
False False
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 2, in u
  File "<string>", line 5, in ?
  File "<string>", line 4, in i
NameError: global name 'y' is not defined

Nope, still dies.  It does seem to be a bug in exec.  I'm
still curious why 'y' was placed into i()'s local namespace
in s().
msg21613 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2004-08-07 21:59
Logged In: YES 
user_id=4771

The behavior you get can be explained quite easy, but it seems nevertheless inconsistent with the documentation: in my opinion it is a serious bug.

The reason the "exec"ed code doesn't work like the same code put at the global module level is that code that runs at the module level always runs with the same dictionary for its globals and locals, whereas in your example you use two different dictionaries.

Assignments always go to the locals; that's why 'y' goes into the dictionary 'e'.  Now a function can only see its own locals and the surrounding globals; that's why execfunc() misses the value of 'y'.  This is the old way Python worked.  In recent versions, a special trick was added so that functions defined inside another function find variable bindings from the enclosing function.  I think you found a case where this trick fails to apply.
msg21614 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2006-02-20 22:06
Logged In: YES 
user_id=849994

Closed #1167300 as a duplicate.
msg82038 - (view) Author: Daniel Diniz (ajaksu2) Date: 2009-02-14 12:47
Confirmed in trunk,
msg84813 - (view) Author: Jeremy Hylton (jhylton) Date: 2009-03-31 15:56
This code behaves as intended.  The module-level execution environment
is different than other environments.  The global scope and local scope
are the same dictionary.  Assignments at the top-level become globals
because of this behavior of the execution environment.  If you want exec
to mimic the top-level environment, you need to pass it a single dictionary.
msg106513 - (view) Author: Colin Hawkett (hawkett) Date: 2010-05-26 07:52
#8819 was closed as duplicate. That issue linked a description of the problem on stack overflow http://stackoverflow.com/questions/2904274/globals-and-locals-in-python-exec. I would like to argue that this is a bug, and should be fixed in 2.6+. The definition of bug here is that python does not behave as documented - that variable name resolution does *not* check the locals() of the enclosing scope. The fact that the code mistakenly assumes locals and globals would be the same thing in this situation does not mean it is not a bug.

The statement in the previous comment - 'if you want exec to mimc the top level environment, you need to pass it a single dictionary' is true, but it hides that fact that this is the *only* thing you can do - if you *don't* want exec to mimic the top level environment, what's the approach? Doing anything else just creates a unique, undocumented, oddly behaving scope that doesn't apply closures correctly.

What are the use cases for passing in locals? Doing so means your code behaves abnormally, unless you think carefully about how you write it, and that's not good - 'Write python code like this, except for this situation where it doesn't work, and you have to write your python like this, avoiding certain closure scenarios that would otherwise work.' What's the exec() API with locals for?

If you don't pass in locals, or make globals and locals the same dictionary, then its an absolute pain to retrieve the definitions created in the exec'd code - they're mixed in with all the globals python adds, and if you don't know in advance what is being defined in the code block, it's close to impossible. To me, this is the primary use case for locals being passed in, and was surely the intention when the API was constructed.  This bug prevents this use case.

I'm guessing that somewhere in the python source there is some code that  goes (pseudo)

if scope == module: check_globals()
else:
  check_locals()
  check_globals()

and that this is done for performance reasons, but surely the check could be different without giving up much, and fix the problem?

if locals() is globals(): check_globals()
else:
  check_locals()
  check_globals()
msg106523 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-05-26 11:40
> I'm guessing that somewhere in the python source there is some code that goes [...]

Unfortunately it's not nearly that simple.  As I mentioned in my message on python-dev, the problem is that 'y' gets bound with a 'STORE_NAME' opcode, which puts 'y' into the locals dict, and then retrieved from within the function with a 'LOAD_GLOBAL' opcode, which looks in the globals dict;  hence the NameError.

So should the compiler be generating a 'LOAD_NAME' instead of a 'LOAD_GLOBAL' for this code?  I'm not really familiar with the compilation process, so I've no idea whether this makes sense, or what impact it might have on existing code.
History
Date User Action Args
2012-06-08 15:04:49terry.reedylinkissue1167300 superseder
2010-05-26 11:40:09mark.dickinsonsetmessages: + msg106523
2010-05-26 08:51:24mark.dickinsonsetnosy: + mark.dickinson
2010-05-26 07:52:54hawkettsetnosy: + hawkett
messages: + msg106513
2010-05-25 18:53:02mark.dickinsonlinkissue8819 superseder
2009-03-31 15:56:24jhyltonsetstatus: open -> closed
resolution: wont fix
messages: + msg84813
2009-03-31 14:37:13jhyltonsetassignee: jhylton

nosy: + jhylton
2009-02-14 12:47:44ajaksu2setnosy: + ajaksu2
type: behavior
messages: + msg82038
versions: + Python 2.6, - Python 2.3
2004-07-14 21:30:23nickjacobsoncreate