[Python-Dev] Is outlawing-nested-import-* only an implementation
issue?
Jeremy Hylton
jeremy@alum.mit.edu
Fri, 23 Feb 2001 11:09:23 -0500 (EST)
>>>>> "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