At 05:49 AM 7/5/2006 +0200, Guido van Rossum wrote:
>>* Alternate spelling of outer names when binding (e.g. ".x = whatever" to
>>bind an outer x)
>
>We looked at and rejected "globals.x = whatever". I think the same
>reasoning applies here.
I thought the 'globals.x' proposal required that 'x' always be accessed
using 'globals', even if it wasn't being rebound. I don't see a problem
with requiring '.x' to be used for both reading and writing of outer-scope
names; it just shouldn't be required for an outer-scope name that you don't
rebind in the current scope. That symmetry requirement can't be
implemented with the 'globals.x' approach unless 'globals' is treated
specially by the compiler.
Using the classic nonsense example:
def counter(num):
def inc():
.num += 1
return .num
return inc
If inc() only needed to *read* num, it could just use 'num' without the
'.', and be nicely backward compatible with today's Python.
(Note: It should be illegal to use both '.num' and 'num' in the same scope,
whether writing or reading the value, to prevent readers from becoming
confused about what variable you mean. It should also be required that the
compiler can see a definition of 'num' in an outer scope if you use the
'.num' syntax, so that misspelling a name doesn't create a global variable.)
I personally think this approach could be the overall least-intrusive
solution as far as syntax goes. It also allows for dropping the 'global'
keyword in 3.x, and it has a nice EIBTI feel to it, as it allows you to
highlight closure variables in an inner function by using the '.'. It's
often not obvious when an inner function (such as a decorator returned by a
decorator factory) is using variables that were defined in the outer scope;
the leading '.' would make them stand out, and so could be considered the
recommended code style when referring to outer variables.
In addition, there's a nice symmetry between nested functions and top-level
functions, e.g. in this global version of the counter example:
num = 0
def inc():
.num += 1
return .num
The principle downside taht I see is that it uses semi-random punctuation
in place of keywords. OTOH, we are already using more-or-less this syntax
for relative imports, so reusing it to mean "relative variables" seems to
at least avoid creating any entirely new principles. :)
Anyway, I won't argue this one further; I just wanted to make sure it had
been considered, as I'm not sure that you were reading the thread where it
was first brought up (possibly as long as a few months ago).
_______________________________________________
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
