[pypy-dev] bug with vars() in a nested function

Rocco Moretti roccomoretti at hotpop.com
Tue Dec 23 16:20:46 CET 2003

holger krekel wrote:

>yes, the main point here is that we probably want to avoid duplicate or
>redundant state, for example calling on interpreter-level 
>    space.builtin.execfile(...)
>and on app-level 
>    __builtin__.execfile(...) 
>should do the same thing but what happens if someone overrides
>__builtin__.execfile from app level?  Do we want the interpreter-level
>to go through this new implementation or should it keep the "real" 
>reference?  It seems tricky to decide this on a case-by-case basis. 
>When doing our recent "implement builtin at app-level and invoke
>interp-level hooks" hack we had a similar consideration with "sys.modules"
>which in CPython can be overriden at applevel but it doesn't affect
>interpreter-level implementations. Otherwise you could get into a
>state that makes it impossible to import anything anymore (e.g.
>consider 'sys.modules = "no dict"'). So i am not sure what we
>want to do about this "duplicate state" issue as there apparently 
>is a flexibility versus security tradeoff involved.  I tend to 
>lean towards "flexibility", though :-)
Fooling around with sys.modules and import on Python2.3 I come away
with the idea that Python's idea that variables are just names helps
us in certain cases. I.e.:

 >>> a = sys.modules
 >>> print a.has_key('random')
 >>> sys.modules = {}
 >>> sys.modules
 >>> import random
 >>> sys.modules
 >>> print a.has_key('random')

So it is the particular dictionary that sys.modules points immediately
after startup that is used by the CPython import mechanism, not the
object that sys.modules is pointing to when the import is called.

This is less help for cases like __import__(), where it's what the
name is pointing to that matters. Although, I suppose we could possibly
handle that through a property-like interface with transparent getters
and setters.


More information about the Pypy-dev mailing list