python exec behaves inconsistent with respect to module imports

[carl.dhalluin at gmail.com]

Hi

Thank you for the explanation

It seems that python behaves different for variables created in the
toplevel namespace, versus deeper namespaces.

CODE:

def g():
  a=2
  print "a in LOC:",locals().has_key('a')
  print "a in GLO:",globals().has_key('a')
  def f():
    print "a in LOC:",locals().has_key('a')
    print "a in GLO:",globals().has_key('a')
    print a
  f()
g()

b=3
print "b in LOC:",locals().has_key('b')
print "b in GLO:",globals().has_key('b')
def h():
  print "b in LOC:",locals().has_key('b')
  print "b in GLO:",globals().has_key('b')
  print b
h()


RESULT:

a in LOC: True
a in GLO: False
a in LOC: True
a in GLO: False
2
b in LOC: True
b in GLO: True
b in LOC: False
b in GLO: True
3


DISCUSSION:

locals() are passed through from a function to a nested function
locals() are not passed if you go from top-level to a nested function.

globals() are visible from all levels
globals() are auto-populated at top level

So now get back to my exec code in the previous post.
The exec applies a mixture of both rules
1. The exec looks at its namespace to apply the rule for globals().
Since I'm not at top-level, variables are not auto-populated in the
globals(), unless I add the keyword 'global' like you suggested.
2. However, the exec applies the other rule for locals(). It does NOT
copy the locals() from one level to the nested one, although it
should.

To me this seems a bug in python exec:
- exec should look at its context to find out if the exec is called
top-level or deeper
- if top-level: auto-populate globals, and do not allow inheritance of
locals to nested levels
- if non top-level: dont populate globals, but allow inheritance of
locals to nested levels.

What do you think?