[Python-Dev] Explicit Lexical Scoping (pre-PEP?) (original) (raw)

Guido van Rossum guido at python.org
Wed Jul 5 10:21:00 CEST 2006

On 7/5/06, Phillip J. Eby <pje at telecommunity.com> 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/)

More information about the Python-Dev mailing list