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

[Boris Borcic]

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.

- what is exactly the sort of assertions independent of run-time details that 
compilers are made to reason about.


> 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é