block scope?

Alex Martelli aleax at mac.com
Sat Apr 7 20:34:34 EDT 2007


Aahz <aahz at pythoncraft.com> wrote:

> In article <1hw7kzo.1hepj3c1who5zhN%aleax at mac.com>,
> Alex Martelli <aleax at mac.com> wrote:
> >Steve Holden <steve at holdenweb.com> wrote:
> >>
> >> What do you think the chances are of this being accepted for Python 3.0?
> >> It is indeed about the most rational approach, though of course it does
> >> cause problems with dynamic namespaces.
> >
> >What problems do you have in mind?  The compiler already determines the
> >set of names that are local variables for a function; all it needs to do
> >is diagnose an error or warning if the set of names for a nested
> >function overlaps with that of an outer one.
> 
> exec?

option 1: that just runs the compiler a bit later -- thus transforming
ClashingVariableError into a runtime issue, exactly like it already does
for SyntaxError.

option 2: since a function containing any exec statement does not
benefit from the normal optimization of local variables, let it also
forgo the normal diagnosis of shadowed/clashing names.

option 3: extend the already-existing prohibition of mixing exec with
nested functions:

>>> def outer():
...   def inner(): return x
...   exec('x=23')
...   return inner()
... 
  File "<stdin>", line 3
SyntaxError: unqualified exec is not allowed in function 'outer' it
contains a nested function with free variables

to prohibit any mixing of exec and nested functions (not just those
cases where the nested function has free variables).


My personal favorite is option 3.


Alex



More information about the Python-list mailing list