> 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 [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