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

[Calvin Spealman]

On 10/16/05, Josiah Carlson <jcarlson at uci.edu> wrote:
>
> Calvin Spealman <ironfroggy at gmail.com> wrote:
> >
> > 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.
>
> What I'm saying is that whether or not you can modify the contents of
> stack frames via tricks, you shouldn't.  Why?  Because as I said, if the
> writer wanted you to be hacking around with a namespace, they should
> have passed you a shared namespace.
>
> From what I understand, there are very few (good) reasons why a user
> should muck with stack frames, among them because it is quite convenient
> to write custom traceback printers (like web CGI, etc.), and if one is
> tricky, limit the callers of a function/method to those "allowable".
> There may be other good reasons, but until you offer a use-case that is
> compelling for reasons why it should be easier to access and/or modify
> the contents of stack frames, I'm going to remain at -1000.

I think I was wording this badly. I meant to suggest this as a way to
define nested functions (or classes?) and probably access names from
various levels of scope. In this way, a nested function would be able
to say "bind the name 'a' in the namespace in which I am defined to
this object", thus offering more fine grained approached than the
current global keyword. I know there has been talk of this issue
before, but I don't know if it works with or against anything said for
this previously.