
"KPY" == Ka-Ping Yee <ping@lfw.org> writes:
No need to go to the source -- this is all clearly explained in the PEP (http://python.sourceforge.net/peps/pep-0227.html).
KPY> It seems not to be that simple, because i was unable to predict KPY> what situations would be problematic without understanding how KPY> the optimizations are implemented. The problematic cases are exactly those where name bindings are introduced implicitly, i.e. cases where an operation binds a name without the name appearing the program text for that operation. That doesn't sound like an implementation-dependent defintion. [...] KPY> That's not the point. There is a scoping model that is KPY> straightforward and easy to understand, and regardless of KPY> whether the implementation is interpreted or compiled, you can KPY> easily predict what a given piece of code is going to do. [Taking you a little out of context:] This is just what I'm advocating for import * and exec in the presence of nested fucntions. There is no easy way to predict what a piece of code is going to do without (a) knowing what names a module defines or (b) figuring out what values the argument to exec will have. On the subject of easy prediction, what should the following code do according to your model: x = 2 def f(y): ... if y > 3: x = x - 1 ... print x ... x = 3 ... I think the meaning of print x should be statically determined. That is, the programmer should be able to determine the binding environment in which x will be resolved (for print x) by inspection of the code. Jeremy