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

Josiah Carlson jcarlson at uci.edu
Sun Oct 16 19:22:14 CEST 2005

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.

More information about the Python-Dev mailing list