> Mechanisms which rely on manipulating variables within closures or
> nested scopes to function properly can be elegant, but I've not yet seen
> one that *really* is.
This really isn't a case for or against what I'm proposing since we
can already do this in today's Python with mutable variables in an
enclosing scope (see below). I am proposing a language change to help
make closures more orthogonal to the scoping constructs that are
already in place for the global scope.
> You state that using classes can be "heavy handed",
> but one of the major uses of classes is as a *namespace*. Many desired
> uses of closures (including the various uses you have outlined)
> is to hide a *namespace*, and combining both closures with classes can offer
> that to you, without requiring a language change.
Closures are also used in more functional styles of programming for
defining customized control structures (those Ruby folks like them for
this purpose). Granted you can do this with classes/objects and
defining interfaces the end result can be somewhat un-natural for some
problems--but I don't want to get into an argument between closures
vs. objects since that is not what my proposal is aimed at and Python
already has both.
> Of course using
> classes directly with a bit of work can offer you everything you want
> from a closure, with all of the explcitness that you could ever want.
Really, the easiest way to emulate what I want in today's Python is to
create a mutable object (like a dict or list) in the enclosing scope
to work around the semantic that the first assignment in a local scope
binds a new name. Doing this seems rather un-natural and forcing the
use of classes doesn't seem more natural
def incgen( inc = 1 ) :
env = [ 6 ]
def incrementor() :
env[ 0 ] += inc
return env[ 0 ]
return incrementor
This is a work around for something a developer cannot do more
naturally today. I do not think using some combination of classes and
closures makes things clearer--it is still working around what I would
construe as the non-orthogonal nature of nested lexical scopes in
Python since the language provides a construct to deal with the
problem for global variables.
a = 6
def incgen( inc = 1 ) :
def incrementor() :
global a
a += inc
return a
return incrementor
Granted this is a somewhat trivial example, but I think it
demonstrates my point about how nested lexical scopes are second class
(since the language has no equivalent construct for them) and don't
behave like the global scope.
> As an aside, you mention both 'use' and 'scope' as possible keyword
> additions for various uses of nested scopes. In my experience, when one
> goes beyond 3 or so levels of nested scopes (methods of a class defined
> within a class namespace, or perhaps methods of a class defined within a
> method of a class), it starts getting to the point where the programmer
> is trying to be too clever.
Even though I may agree with you on this, your argument is more of an
argument against PEP 227 than what I am proposing. Again, today's
Python already allows a developer to have deep nested scopes.
-Almann
--
Almann T. Goo
[EMAIL PROTECTED]
_______________________________________________
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
