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

[Jeremy Hylton]

>>>>> "KPY" == Ka-Ping Yee <ping@lfw.org> writes:

  >> Another key difference between Scheme and Python is that in
  >> Scheme, each binding operation creates a new scope.

  KPY> Scheme separates 'define' and 'set!', while Python only has
  KPY> '='.  In Scheme, multiple defines rebind variables:

Really, scheme provides lambda, the let family, define, and set!, where
"define" is defined in terms of letrec except at the top level.

  KPY>     (define a 1)
  KPY>     (define a 2)
  KPY>     (define a 3)

Scheme distinguishes between top-level definitions and internal
defintions.  They have different semantics.  Since we're talking about
what happens inside Python functions, we should only look at what
define does for internal definitions.

An internal defintion is only allowed at the beginning of a body, so
you're example above is equivalent to:

(letrec ((a 1) (a 2) (a 3)) ...)

But it is an error to have duplicate name bindings in a letrec.  At
least it is in MzScheme.  Not sure what R5RS says about this.

  KPY> just as in Python, multiple assignments rebind variables:

  KPY>     a = 1 
  KPY>     a = 2 
  KPY>     a = 3

Python's assignment is closer to set!, since it can occur anywhere in
a body not just at the beginning.  But if we say that = is equivalent
to set! we've got a problem, because you can't use set! on an unbound
variable.

I think that leaves us with two alternatives.  As I mentioned in my
previous message, one is to think about each assignment in Python
introducing a new scope.

a = 1                             (let ((a 1))
a = 2                                 (let ((a 2))
a = 3                                     (let ((a 3))
                                              ....)))
or

def f():                          (define (f)
    print a                           (print a)
    a = 2                             (let ((a 2))
                                           ...))

But I don't think it's clear to read a group of equally indented
statements as a series of successively nested scopes.  The other
alternative is to say that = is closer to set! and that the original
name binding is implicit.  That is: "If a name binding operation
occurs anywhere within a code block, all uses of the name within the
block are treated as references to the local namespace."  (ref manual,
sec. 4)

  KPY> The lack of 'set!' prevents Python from rebinding variables
  KPY> outside of the local scope, but it doesn't prevent Python from
  KPY> being otherwise consistent and having "a = 2" do the same thing
  KPY> inside or outside of a function: it binds a name in the current
  KPY> scope.

Again, if we look at Scheme as an example and compare = and define,
define behaves differently at the top-level than it does inside a
lambda.

Jeremy