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

[Bengt Richter]

At 19:05 2003-12-23 +0100, you (holger krekel) wrote:
>[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.

Maybe the original binding could be preserved as sys.__modules__
analogously to sys.__stdout__ ?

>I guess that CPython's keeping reference to the original dict object
>is more a performance hack and also shields from stupid errors ...

I don't know. Isn't it normal to get a binding through a name and then
ignore the name? Mutating the referenced object is a different matter
though, e.g.,

>>> import sys
>>> a = sys.modules
>>> print a.has_key('random')
False
>>> sys.modules.clear()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
RuntimeError: lost __builtin__

Just a couple of thoughts.

>> This is less help for cases like __import__(), where it's what the
doesn't __import__ look for the name in the same original sys.modules?

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

If the interpreter has to maintain some objects to survive, maybe apps
should only get access via readonly/proxy mechanisms of some kind? 

Disclaimer: I'm only reacting in the context of this one email,
so please ignore if it doesn't make sense ;-)

Bengt