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

[Almann T. Goo]

On 2/26/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> Then do you also dislike the original proposal: that only a single dot
> be allowed, and that the '.' would mean "this name, but in the nearest
> outer scope that defines it"?  Then:
>
>     def incrementer_getter(val):
>        def incrementer():
>            val = 5
>            def inc():
>                .val += 1
>                return val
>            return inc
>        return incrementer
>
> would do what I think you want it to[1].  Note that I only suggested
> extending the dot-notation to allow multiple dots because of Greg
> Ewing's complaint that it wasn't enough like the relative import
> notation.  Personally I find PJE's original proposal more intuitive,
> and based on your example, I suspect so do you.
>
> [1] That is, increment the ``val`` in incrementer(), return the same
> ``val``, and never modify the ``val`` in incrementer_getter().

I'm not sure if I find this more intuitive, but I think it is more
convenient than the "explicit dots" for each scope.  However my
biggest issue is still there.  I am not a big fan of letting users
have synonyms for names.  Notice how ".var" means the same as "var" in
some contexts in the example above--that troubles me.  PEP 227
addresses this concern with regard to the class scope:

    Names in class scope are not accessible.  Names are resolved in
    the innermost enclosing function scope.  If a class definition
    occurs in a chain of nested scopes, the resolution process skips
    class definitions.  This rule prevents odd interactions between
    class attributes and local variable access.

As the PEP further states:

    An alternative would have been to allow name binding in class
    scope to behave exactly like name binding in function scope.  This
    rule would allow class attributes to be referenced either via
    attribute reference or simple name.  This option was ruled out
    because it would have been inconsistent with all other forms of
    class and instance attribute access, which always use attribute
    references.  Code that used simple names would have been obscure.

I especially don't want to add an issue that is similar to one that
PEP 227 went out of its way to avoid.

-Almann

--
Almann T. Goo
almann.goo at gmail.com