On 7/5/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > 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).
Thanks for bringing this up. I'm not sure what I think of it yet. One problem I see is that there might end up being two ways to reference variables in outer scopes: .num if you plan to assign to it, or just num if you only reference it. I find that the most disurbing issue so far; modified global declarations or outer declarations don't have this problem. Would this also use ..num to refer to num in an outer scope two levels removed? -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
