One last shot at the Augmented Assignment PEP

[Tim Peters]

[Bob Alexander]
> ...
> As a proponent of *true* augmented assignment, though, I suggest we
> rename that new feature in Python to something more appropriate to
> the definition.  Like "sometimes-augmented sometimes-assignment". Or
> "totally new operators having little to do with assignment".

The problem with those names is that they're very long <wink>.  Guido was
looking for a short name, and I'm afraid you can blame me for borrowing the
Icon name, but have to blame years of preceding argument for not borrowing
Icon's semantics in all respects.  Think of "augmented" as describing the
mere *appearance* of the symbols, and it shouldn't hurt so much <0.9 wink>
("huh, I guess '<<=' is an assignment thingie augmented by a shift doodad?"
"right!").

Python's an object-oriented language with a very meat-&-potatoes view of
objects:  they're things that have state, and depending on the kind of thing
its state may or may not be mutable.  That's up to the kind of thing a thing
is <ahem -- I'm avoiding the words "type" and "class" to keep it at the spam
& homefries level>.  There's no philosophical bias toward favoring one kind
over the other in Python, so it's a mundane fact of Python life that you
deal with both kinds all the time.  Objects with mutable state generally
*like* to have it mutated.  If you don't believe that, just ask the next
mutable object you see!  Mutable objects that would rather be left alone are
also welcome in Python, but most of them moved to other languages long ago.
So, sure, it's a bit self-selecting, but we're catering to the objects that
elected to stay.

> ...
> And then there's
>
>     tup = ()
>     lst = []
>     tup += (33)
>     lst += [33]
>
> The last two lines look about the same but have different semantics!

Constrast with:

    x.f(a)
    y.f(a)

Who knows?  Can't tell -- not in Python.  In an OO language with
overloadable operator symbols, it's the *virtue* of overloading that you get
"better-looking" ways to spell method calls.  It's not the language's place
to say "ya, screw you, only non-mutating methods can be spelled more
nicely".  If Stroustrup had come up with a pithy name for the same gimmick
in C++, I would have suggested using that instead because C++'s reasons for
allowing += etc to be overloaded in distinct ways from + etc coincide with
Python's.  Icon had different goals in mind.  I just borrowed the *name*
from Icon, so that people opposing it could use a short recognizable phrase
in their Subject lines <wink>.

[Steve Holden]
> ...
> There seems to be a more autocratic feel to recent changes, but
> then the BDFL has earned the right to go his own way, not matter
> how ill-advised we lesser mortals may feel the path to be.

Due to legal shenanigans delaying releases, Guido found himself with a
couple extra months on his hands before the *planned* release.  So, rather
than waste time doing something silly (like, say, speeding Python up
<wink>), he decided to clear out a backlog of language changes he had been
*intending* to make-- in some cases --since the mid 90's.  There's very
little that went in that hadn't been debated to death multiple times already
at worst a year ago.  We started the PEP process at the same time, and it's
unfortunate that most of the initial PEPs are doomed to describe ideas whose
most energetic debates ended long ago.  BTW, Guido appreciates it when
people admit they're "lesser mortals", but prefers that you *start* your
arguments by groveling <wink>.

[back to Bob]
> ...
> Is it really too late to change this? 2.0 isn't final yet.

Honest to Guido, Bob, I think it was too late to change this one already by
the end of 1997.  That's what you get for hanging out with the wrong
languages all those years <wink>.

"comprehensions"-don't-have-much-contact-left-with-set-theory-
    either-ly y'rs  - tim