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

[holger krekel]

[Rocco Moretti Tue, Dec 23, 2003 at 09:20:46AM -0600]
> 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')
> False
>  >>> sys.modules = {}
>  >>> sys.modules
> {}
>  >>> import random
>  >>> sys.modules
> {}
>  >>> print a.has_key('random')
> True
>  >>>
> 
> 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.

Yes, but is it what we want to mimic?  Somehow i think the idea is that
sys.modules is the one place where modulepath-moduleobject mappings
should be kept and the interpreter level should consult this object. 
I guess that CPython's keeping reference to the original dict object
is more a performance hack and also shields from stupid errors ...

> 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.

We can always special case but i'd prefer a general solution like 
"interp-level has to go through the applevel hooks/names" but maybe
this is not feasible. 

    holger