[Python-Dev] violently deprecating exec without in (was: nested scopes. global: have I got it right?)
Samuele Pedroni
pedroni@inf.ethz.ch
Fri, 2 Mar 2001 00:22:20 +0100
Hi.
> > x=7
> > def f():
> > global x
> > def g():
> > exec "x=3"
> > return x
> > print g()
> >
> > f()
> >
> > prints 3, not 7.
>
> I've been meaning to reply to your original post on this subject,
> which actually addresses two different issues -- global and exec. The
> example above will fail with a SyntaxError in the nested_scopes
> future, because of exec in the presence of a free variable. The error
> message is bad, because it says that exec is illegal in g because g
> contains nested scopes. I may not get to fix that before the beta.
>
> The reasoning about the error here is, as usual with exec, that name
> binding is a static or compile-time property of the program text. The
> use of hyper-dynamic features like import * and exec are not allowed
> when they may interfere with static resolution of names.
>
> Buy that?
Yes I buy that. (I had tried it with the old a2)
So also this code will raise an error or I'm not understanding the point
and the error happens because of the global decl?
# top-level
def g():
exec "x=3"
return x
For me is ok, but that kills many naive uses of exec, I'm wondering if it
does not make more sense to directly take the next big step and issue
an error (under future nested_scopes) for *all* the uses of exec without in.
Because every use of a builtin will cause the error...
regards