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

Discussion in 'Python' started by Crutcher, Dec 31, 2005.

  1. Crutcher

    Crutcher Guest

    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>)
    Crutcher, Dec 31, 2005
    #1
    1. Advertising

  2. Crutcher <> 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
    Alex Martelli, Dec 31, 2005
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steven D'Aprano
    Replies:
    4
    Views:
    261
    Hrvoje Niksic
    May 4, 2009
  2. Baz Walter
    Replies:
    6
    Views:
    276
    Grant Edwards
    May 3, 2010
  3. Baz Walter
    Replies:
    5
    Views:
    228
    Baz Walter
    May 4, 2010
  4. Baz Walter
    Replies:
    26
    Views:
    561
    Nobody
    May 6, 2010
  5. Cameron Simpson

    Re: strange interaction between open and cwd

    Cameron Simpson, May 4, 2010, in forum: Python
    Replies:
    6
    Views:
    217
    Albert van der Horst
    May 12, 2010
Loading...

Share This Page