Strange interaction between exec, dictionary subtypes, and global variables in 2.4

[Crutcher]

I've been playing with dictionary subtypes for custom environments,
and I encountered a strange interaction between exec, dictionary
subtypes, and global variables. I've attached a test program, but
first I'd like to give some background.

Python uses dictionary objects as symbol tables in it's execution
contexts. Since these objects used to be basic types, which were not
subclassable, some of the interpreter code accessed them using
low-level C functions.

Then dictionary types were made subclassable, and I was pretty
excited, because I wanted to use them to set up custom execution
environments with extended semantics. This didn't work, because when
the dictionary types were made subclassable, the interpreter code
which used them as symbol tables was not changed, so subclassed
dictionaries used in exec statements or eval calls bypassed their
subclass functions, and jumped straight to the underlying C functions.

In python 2.4, this was finally fixed, and you can now use subclassed
dictionaries in exec statements and eval calls.

Except that there is some niggling edge case dealing with variables
which have been marked 'global'. It seems that if a compiled chunk of
python contains a 'global VAR' statement, anywhere, then that VAR, and
only that VAR, will bypass the subclassed functions when it is
accessed.

I'd like to fix this, and send it upstream, and I've worked on
extensive python/C bindings before, but I've not hacked the
interpreter. I took a look around, and I'm not sure where the symtable
lookup is happening.

However, I have some belief that someone on this list _may_ be able to
point me in the right direction.

#!/usr/bin/python2.4

class TypedDictionary(dict):
def __setitem__(self, key, value):
print '__setitem__(%s, %s)' % (key, value)
if self.has_key(key):
t = type(self[key])
try:
value = t(value)
except Exception:
raise TypeError, \
"illegal assignment to '%s': %s cannot be coerced to %s" \
% (key, type(value), t)
dict.__setitem__(self, key, value)

test_script = """
foo = 0
bar = 'xyz'
print 'foo:', repr(foo), '; bar:', repr(bar)

foo = '1'
bar = 42
print 'foo:', repr(foo), '; bar:', repr(bar)
"""

print "Without 'global foo':"
exec test_script in TypedDictionary()

print

print "With 'global foo':"
exec test_script + """
def f():
global foo
pass
""" in TypedDictionary()


This program produces this output:
Without 'global foo':
__setitem__(foo, 0)
__setitem__(bar, xyz)
foo: 0 ; bar: 'xyz'
__setitem__(foo, 1)
__setitem__(bar, 42)
foo: 1 ; bar: '42'

With 'global foo':
__setitem__(bar, xyz)
foo: 0 ; bar: 'xyz'
__setitem__(bar, 42)
foo: '1' ; bar: '42'
__setitem__(f, <function f at 0x40230454>)

 

[Alex Martelli]

Except that there is some niggling edge case dealing with variables
which have been marked 'global'. It seems that if a compiled chunk of
python contains a 'global VAR' statement, anywhere, then that VAR, and
only that VAR, will bypass the subclassed functions when it is
accessed.

As we covered on another mailing list today, the presence of that
'global VAR' anywhere means that accesses to that variable get compiled
into bytecodes LOAD_GLOBAL, STORE_GLOBAL, instead of the LOAD_NAME,
STORE_NAME produced when no 'global VAR' is around; and looking at
ceval.c, we see that the use of dictionary subclasses is only supported
for f_locals -- f_globals (and f_builtins) are always used as 'exact'
dict instances instead. I consider that a bug, even though there might
be a (hopefully miniscule) slowdown in supporting dict subclasses for
f_globals as well as for f_locals. I know you're now working on a patch
for the issue (and I repeat my recommendation of adding a unit-test for
this issue as part of your patch)... let's see what comes up (the
python-dev mailing list may be more appropriate for this discussion,
btw, since it IS about the development of Python).


Alex