[Python-Dev] Explicit Lexical Scoping (pre-PEP?) (original) (raw)

Boris Borcic bborcic at gmail.com
Wed Jul 12 16:36:28 CEST 2006

Terry Reedy wrote:

"Boris Borcic" <bborcic at gmail.com> wrote in message news:e90j6o$fij$1 at sea.gmane.org...

I agree with you (and argued it in "scopes vs augmented assignment vs sets" recently) that mutating would be sufficient /if/ the compiler would view augmented assignment as mutations operators : Mutation is an operation on objects. Binding is an operation on namespaces. The difference between objects and namespaces (and the actions thereupon) is fundamental to Python.

If you want to put it that way, but I think it muddies the relevant water to confuse scopes with namespaces, or compiler with interpreter responsibilities.

Deciding whether an augmented assignment results in a bona-fide mutation or in the rebinding of an already bound name in an unchanging namespace : that's the responsibility of the interpreter. [Well, nowa-pypy-days I guess we should say, not even of the interpreter, but of the object space].

Deciding how names bind to lexical scopes, that's the responsibility of the compiler. When faced with such code as below [ while mutable_int() might as well equal (lambda x : x) as far as the compiler is concerned ]

  def counter(num):
      num = mutable_int(num)
      def inc():
          num += 1
          return num
      return inc

It is disingenuous that the /scope-binding phase/ of the compiler design feigns to believe that my "num += 1" is really more like "num = 2" than it is like a mutation operator, given that :

     whether the statement ultimately results in REbinding or mutation
     is /irrelevant/ to the fact that any augmented assignment requires
     an autonomous initial binding of the variable to ever function.

Asking the interpreter to view one thing as something else which it isn't can only lead to more confusion.

I think its impossible to be more confused than setting things up so that the programmer of counter() above gets :

UnboundLocalError: local variable 'num' referenced before assignment

When what is really meant is (your drift no ?) :

<< We think allowing you what you want would make

a=b=c ; a += d ; b = b+d ; assert a == b

more difficult for newbies to understand and predict in context >>

In particular, asking that arithmetic operations on immutable numbers be seen as mutations seems wacky to me.

Nobody really asked for this (I invite you to check), but even so I feel an exact analysis of the impact on use-cases would be worth its while.

which it doesn't as far as concerns scopes where a variable appears as target only of /augmented/ assignments. The interpreter/compiler, as far as I can think, never views binding as mutation, nor should it. The request that it do so

The request is not for the "compiler/interpreter" to view binding as mutation, it is for the /compiler/ to view /REbinding/ just like mutation - which it is as far as compiler responsibilities are concerned imo.

makes me wonder whether it might have been a mistake to allow mutable objects in an augmented assignment to choose to implement the associated operation as an in-place mutation.

I agree with you that removing this possibility would provide better consistency to your position.

Best regards, Boris Borcic

"C++ is a contradiction in terms" - Lorentz, Einstein, Poincaré

More information about the Python-Dev mailing list