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

Josiah Carlson jcarlson at uci.edu
Wed Oct 19 20:58:06 CEST 2005


Calvin Spealman <ironfroggy at gmail.com> wrote:
> On 10/16/05, Josiah Carlson <jcarlson at uci.edu> wrote:
[snip]
> > 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.

And as I have said, if you want people to modify a namespace, you should
be creating a namespace and passing it around.  If you want people to
have access to some embedded definition, then you expose it.  If some
writer of some module/class/whatever decides that they want to embed
some thing that you think should have been exposed to the outside world,
then complain the the writer that they have designed it poorly.

Take a walk though the standard library.  You will likely note the
rarity of embedded function/class definitions.  In those cases where
they are used, it is generally for a good reason.

You will also note the general rarity of stack frame access.  Prior to
the cycle-removing garbage collector, this was because accessing stack
frames could result in memory leaks of stack frames.  You may also note
the rarity of modification of stack frame contents (I'm not sure there
are any), which can be quite dangerous.  Right now it is difficult to go
and access the value of a local 'x' three callers above you in the stack
frame.  I think this is great, working as intended in fact.  Being able
to read and/or modify arbitrary stack frame contents, and/or being able
to pass those stack frames around: foo(frame[3]), is quite dangerous.

I'm still -1000.

 - Josiah



More information about the Python-Dev mailing list