Terry Reedy wrote:
> "Boris Borcic" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> 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é
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
