On 2/26/06, Steven Bethard <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
