On 10/16/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > 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.
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. _______________________________________________ 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
