[Python-Dev] Early PEP draft (For Python 3000?)

[Calvin Spealman]

On 10/14/05, Josiah Carlson <jcarlson at uci.edu> wrote:
>
> Calvin Spealman <ironfroggy at gmail.com> wrote:
> >
> > On 10/11/05, Eyal Lotem <eyal.lotem at gmail.com> wrote:
> > >       locals()['x'] = 1 # Quietly fails!
> > > Replaced by:
> > >       frame.x = 1 # Raises error
> >
> > What about the possibility of making this hypothetic frame object an
> > indexable, such that frame[0] is the current scope, frame[1] is the
> > calling scope, etc.? On the same lines, what about closure[0] for the
> > current frame, while closure[1] resolves to the closure the function
> > was defined in? These would ensure that you could reliably access any
> > namespace you would need, without nasty stack tricks and such, and
> > would make working around some of the limitation of the closures, when
> > you have such a need. One might even consider a __resolve__ to be
> > defined in any namespace, allowing all the namespace resolution rules
> > to be overridden by code at any level.
>
> -1000  If you want a namespace, create one and pass it around.  If the
> writer of a function or method wanted you monkeying around with a
> namespace, they would have given you one to work with.

If they want you monkeying around with their namespace or not, you can
do so with various tricks introspecting the frame stack and other
internals. I was merely suggesting this as something more
standardized, perhaps across the various Python implementations. It
would also provide a single point of restriction when you want to
disable such things.

> As for closure monkeywork, you've got to be kidding.  Closures in Python
> are a clever and interesting way of keeping around certain things, but
> are actually unnecessary with the existance of class and instance
> namespaces. Every example of a closure can be re-done as a
> class/instance, and many end up looking better.

i mostly put that in there for completeness.