Augmented assignment should never modify the assign target!

[Alex Martelli]

"Eric Jacobs" <eaj at ricochet.net> wrote in message
news:200009072155.QAA18487 at rgate4.ricochet.net...
    [snip]
> (You could say that augmented assignment splits sequence types
> into two abstract types: always in-place sequence and never
> in-place sequence.

Exactly!  And += behaves polymorphically and appropriately
for either kind: rebinding the reference it's applied to, if
the object is immutable; mutating the object, if it's mutable.
Lovely, IMHO, because this is *just* what I need in most cases.

Not just sequence types, either.  This abstraction applies
to every augmented-assignment operation, and to every object
uniformly.

If a language has mutable objects at all (i.e., excepting
Haskell:-), that's exactly how I want it to behave in
general: *polymorphically* between mutable and immutable
kinds.  There should be an easy way to query which kind
an object falls in: I think (hope I'm wrong...?) this is
currently lacking.  Such a query would help code that
needs to "get my own copy that won't change" if need be:

    if ismutable(theobject):
        mycopy = copy.copy(theobject)
    else
        mycopy = theobject

I think the need for such a query should be fairly
uncontroversial.  More controversial would be to have
some kind of COW (copy-on-write) 'smart reference', so
I'm not going to pursue this latter course for now:-).


> > IMO, removing the in-place stuff would prevent unnecessary and misguided
> > complication of the language.
>
> Absolutely. In-place modification should be considered
> completely indepenendently from augmented assignment.

That would substantially impoverish augmented-assignment
to the role of mere substanceless syntactic sugar.  I'm
*VERY, VERY* happy that such a sterile course wasn't pursued.

> Python may have only been a 95% language, but I have a
> feeling it's about to drop a letter grade :(

In my book, it's gone up [[well, it would have had it
not been for the print>> blotch, which is such a <expletive
deleted> as to _almost_ outweigh the beauty of augmented
assignment and list comprehensions.  But that's a separate
flame]].  My feeling about augmented assignment is that it
was done *JUST RIGHT*, pointing to very good polymorphic
behaviour of mutable and immutable objectkinds.  Let's have
more of that (e.g., a mutable "stringbuffer" quasistring
object that mimics all of the behavior of string objects
except that it's mutable and does mutate inplace with every
method where that makes sense -- just an off-the-cuff example).


Alex