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

[Almann T. Goo]

> 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