Calvin Spealman <[EMAIL PROTECTED]> wrote: > > On 10/14/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > > > Calvin Spealman <[EMAIL PROTECTED]> wrote: > > > > > > On 10/11/05, Eyal Lotem <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
