RetroSearch Browse

Fri Oct 14 09:23:44 CEST 2005 · http://mail.python.org/pipermail/python-dev/2005-October/057309.html

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.

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.

 - Josiah

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2005-October/057309.html below:

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