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

[Josiah Carlson]

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.

 - Josiah