On 10/14/05, Josiah Carlson <jcarlson@uci.edu> wrote:
Calvin Spealman <ironfroggy@gmail.com> wrote:
On 10/11/05, Eyal Lotem <eyal.lotem@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.
As for closure monkeywork, you've got to be kidding. Closures in Python are a clever and interesting way of keeping around certain things, but are actually unnecessary with the existance of class and instance namespaces. Every example of a closure can be re-done as a class/instance, and many end up looking better.
i mostly put that in there for completeness.