[Python-Dev] Using and binding relative names (was Re: PEP for Better Control of Nested Lexical Scopes) (original) (raw)

Almann T. Goo almann.goo at gmail.com
Thu Feb 23 07:28:24 CET 2006

If we wanted to be fully consistent with the relative import mechanism, we would require as many dots as nested scopes.

At first I was a bit taken a back with the syntax, but after reading PEP 328 (re: Relative Import) I think I can stomach the syntax a bit better ; ).

That said, -1 because I believe it adds more problems than the one it is designed to fix.

Part of me can appreciate using the prefixing "dot" as a way to spell "my parent's scope" since it does not add a new keyword and in this regard would appear to be equally as backwards compatible as the ":=" proposal (to which I am not a particularly big fan of either but could probably get used to it).

Since the current semantics allow evaluation to an enclosing scope's name by an "un-punctuated" name, "var" is a synonym to ".var" (if "var" is bound in the immediately enclosing scope). However for re-binding to an enclosing scope's name, the "punctuated" name is the only one we can use, so the semantic becomes more cluttered.

This can make a problem that I would say is akin to the "dangling else problem."

def incrementer_getter(val):
   def incrementer():
       val = 5
       def inc():
           ..val += 1
           return val
       return inc
   return incrementer

Building on an example that Steve wrote to demonstrate the syntax proposed, you can see that if a user inadvertently uses the enclosing scope for the return instead of what would presumably be the outer most bound parameter. Now remove the binding in the incrementer function and it works the way the user probably thought.

Because of this, I think by adding the "dot" to allow resolving a name in an explicit way hurts the language by adding a new "gotcha" with existing name binding semantics.

I would be okay with this if all name access for enclosing scopes (binding and evaluation) required the "dot" syntax (as I believe Steve suggests for Python 3K)--thus keeping the semantics cleaner--but that would be incredibly backwards incompatible for what I would guess is a lot of code. This is where the case for the re-bind operator (i.e. ":=") or an "outer" type keyword is stronger--the semantics in the language today are not adversely affected.

-Almann

Almann T. Goo almann.goo at gmail.com

More information about the Python-Dev mailing list