(switching lists to python-ideas, dropping python-dev and python-checkins) Context for anyone not following python-checkins: I recently moved PEP 3150 (statement local namespaces) to Withdrawn, rewrote PEP 403 with a different syntax proposal, retitled it to "Statement local class and function definitions" and moved it to Deferred. On Fri, Feb 24, 2012 at 2:37 AM, Jim Jewett <jimjjewett@gmail.com> wrote:

I understand that adding a colon and indent has its own problems, but ... I'm not certain this is better, and I am certain that the desire for indentation is strong enough to at least justify discussion in the PEP.

Fair point. The reason for the flat structure is that allowing a full suite screws with the scoping rules and gets us into the land of insane complexity that was PEP 3150. A decorator-inspired syntax makes it very clear (both to the reader and to the compiler) that there's only *one* name being forward referenced, rather than potentially hiding declarations of forward references an arbitrary distance from the statement that uses them. This doesn't actually lose any flexibility, since you can just make a forward reference to a class instead and use that as your local namespace (with ordinary attribute access semantics), rather than the brain-bender that was the proposed scoping rules for PEP 3150's given clause. The only other alternative syntax would be to use a custom suite definition that allowed only a single class or function definition statement, but I think having something that looks like a suite, but isn't one would be significantly worse than the current proposed syntax that merely allows a function (or class) definition's implied local name binding to be overridden with a custom statement. To (almost*) recreate the effect of an ordinary function definition with the in statement, you could write: in f = f def f(): pass And a decorated definition like: @deco1 @deco2 @deco3 def f(): pass Could (almost*) be expressed as: in f = deco1(deco2(deco3(f))) def f(): pass * The reason for the "almost" caveat is that, given the current PEP 403 semantics, recursive references to f() will resolve differently for the "in" statement cases - for the in statement, they will resolve directly to the innermost function definition, while for ordinary definitions they will be resolved according to the scoping rules for any name lookup. This could be an argument in favour of allowing *decorated* function and class definitions, rather than requiring that they be undecorated - if decorators are allowed, then recursive references would resolve directly to the post-decorated version. Alternatively, people could adopt a convention of prepending an underscore to the actual function name in cases where it mattered, meaning they would have easy access to *both* forms of the function (decorated and undecorated): in f = deco1(deco2(deco3(_f))) def _f(): return f, _f # decorated, undecorated In either case, whereas an ordinary recursive function definition can get confused by reassignments in the outer scope, an in-statement based definition would be truly recursive (via a cell reference) and hence ignore any subsequent changes in the outer namespace. Something else the PEP should mention explicitly is that, like __class__, a class object obviously won't be available while the class body is being executed. Only methods will be able to refer to the class by name, just as only methods can use __class__. Updates to PEP 403 are going to be pretty sporadic until some time after 3.3 release though - it's still very much in "this is a problem I am thinking about" territory rather than "this is a language addition I am proposing" (the latest round of updates were just to make sure I recorded my latest idea before I forgot about the details). Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia