Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Strange interaction between exec, dictionary subtypes, and global variables in 2.4

Reply
Thread Tools

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

 
 
Crutcher
Guest
Posts: n/a
 
      12-31-2005
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>)

 
Reply With Quote
 
 
 
 
Alex Martelli
Guest
Posts: n/a
 
      12-31-2005
Crutcher <(E-Mail Removed)> wrote:
...
> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: strange interaction between open and cwd Cameron Simpson Python 6 05-12-2010 11:25 AM
Re: strange interaction between open and cwd Baz Walter Python 26 05-06-2010 04:16 AM
Re: strange interaction between open and cwd Baz Walter Python 5 05-04-2010 12:53 PM
strange interaction between open and cwd Baz Walter Python 6 05-03-2010 04:34 PM
Strange interaction between timeit and recursion Steven D'Aprano Python 4 05-04-2009 07:53 AM



Advertisments