[pypy-dev] bug with vars() in a nested function
roccomoretti at hotpop.com
Tue Dec 23 00:16:00 CET 2003
Laura Creighton wrote:
To be honest, I'm not quite catching your entire meaning ... So I'll
just babble and hope something of what I say strikes close to the mark.
>I am now looking at our current crop of builtins, and thinking ...
>'the only reason you lot are there is because CPython had you there'.
>Now that we have hacked the architecture one more time again, grin,
>we have something a lot cleaner (for now at any rate) ... I am
>pushing for a more elegant definition of builtin, based on a
>pragmatic idea of 'you have to be built in becauswe we cannot make
>you any other way'
Clarity is strained by the two connotations of "builtin" (i.e. 'always
present') that can be meant. That is (for the CPython interpreter):
* Written in C and statically linked to the interpreter.
(Always present in the interpreter.)
* Available in Python without having to import anything.
(Always present in the language.)
I'm under the impression that the __builtin__ module is so named for the
second point, as there are a number of modules which meet the first
point. (There happen to be 39 on my copy of CPython -
PyPy's __builtin__ *has* to meet point #2 - otherwise it wouldn't be
Python. But I agree with you on point #1 -- We should push to
application level everything we can, and have the interpreter level be
the absolute minimum needed in order to make it run.
>What of ours make it? Which cannot be made in app space and why,
>given that interp space is dead? I think that we have gloriously
>moved to a place where most of our builtins really do not have to be.
>Some sort of execfile sort of thing is all we need.
>This is probably wrong, and indicates that my vision is too idealised,
>and I miss very real practical problems. I await more enlightenment.
>But I still think that most of our 'builtins' are more 'reimplentations
>of CPython builtins, done because CPython doesn't have them so we
>couldn't have a working Python without them'. And we could
>implement them as a module. When we have leftovers, real
>problems in converting one object space to another, then things
>like getdictscope -- or a more general thing that does this and more
>actually -- strikes me as a thing that belongs __there__. Scoping
>rules strike me as object space 'required things to leave a hook
Let me clarify - are you just referring to the __builtin__ module, or
are you advocating a more expansive redesign where ObjSpace and
interpreter core gets uplifted to App level?
> But perhaps I am just confused again, and oversimplifying in my mind.
I definitely agree with Laura. We should strive to push as much as
possible to application level, for no other reason than it will make
doing annotations, etc. easier.
But there needs to be a good mechanism to provide interpreter level
hooks for the app level functions.
Take __import__. There is currently a commented out application level
version in the builtin module. The __import__ functionality would work
fine at application level, except for a few minor issues. You can't get
sys.modules from app level, as that would require you to 'import sys',
which leads to obvious recursion. Same goes for accessing the filesystem
tools in os and os.path. The way the app level function works now is
that it defines a set of interpreter level helpers which are able to
access the functionality and pass it back. The problem with the way they
are implemented now is that all those helpers pollute the __builtin__
If there was a good way to define interpreter level helpers which were
visible from *within* the module, but invisible from the outside, then I
feel this approach would work well, and we can extend it to pare the
interpreter level functionality down to the bare minimum.
More information about the Pypy-dev