[pypy-dev] bug with vars() in a nested function
Bengt Richter
bokr at oz.net
Tue Dec 23 23:30:31 CET 2003
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
More information about the Pypy-dev
mailing list