[Python-Dev] PEP for Better Control of Nested Lexical Scopes (original) (raw)

Almann T. Goo almann.goo at gmail.com
Tue Feb 21 07:09:38 CET 2006

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 almann.goo at gmail.com

More information about the Python-Dev mailing list