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

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