Home Original page

One last shot at the Augmented Assignment PEP

Alex Martelli aleaxit at yahoo.com
Wed Sep 13 18:22:21 EDT 2000 
"Bob Alexander" <balexander at rsv.ricoh.com> wrote in message
news:39BFC44E.FD6CB79C at rsv.ricoh.com...
    [snip]
>     tup += (33)
>     lst += [33]
>
> The last two lines look about the same but have different semantics! In

Isn't it great?  It's called "polymorphism".  The same mechanism
whereby, say:
    i+j
always looks the same but has different semantics when i and j are
numbers from when they are sequences.

> pure augmented assignment the semantics would be parallel, and would be

They _are_ *parallel*.  Remember that parallel lines never meet...

> exactly what is suggested by the two characters of the "+=" operator.

Consider the sequence of statements:
    a = copy(x)
    b = copy(x)
    a = a + y
    b += y
    assert a==b

This seems a pretty good operational definition to me, for the
semantic equivalence of the 3rd and 4th statements.  "When
operating on variables bound to identical copies of some object,
they leave each variable bound to an object such that the two
variables compare-equal".

Without the polymorphism over mutable objects wrt immutable
ones, += and its ilk would be mere syntactic sugar of no big
real interest.  WITH the polymorphism, they become a precious
innovation.  Call them "mutation-suggestors with fallback to
rebinding if the object is immutable", if you wish, because that
is what they are.  "Augmented-assignments" is a more concise
name (and since so-called "assignment" in Python is not really
what programmers of C, Fortran, etc, think of as "assignment",
but, actually, it's *binding* [or re-binding], I'm not in the least
perturbed by "assignment" being used in that concise name --
it's not any more misleading than using it for 'a=b'...:-).

A brilliant design, is my opinion...


Alex
More information about the Python-list mailing list