Re: [Python-Dev] Is outlawing-nested-import-* only an implementation issue?

23 Feb 2001

      ...
...
...
...
...
"KPY" == Ka-Ping Yee  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

Re: [Python-Dev] Is outlawing-nested-import-* only an implementation issue?

Jeremy Hylton