One last shot at the Augmented Assignment PEP

[Bob Alexander]

My collected responses to several posts on this topic:


> How about using = for assignment and ! for augmentation?
> 
> a = b = [];   a += [1]   # a==[1] and b==[]
> a = b = [];   a +! [1]   # a==[1]==b
> 
> a = b = ();   a += (1,)  # a==(1,) and b==()
> a = b = ();   a +! (1,)  # Error, () is immutable.

I like this idea a lot. "!" has been used in other contexts to indicate
"destructive operation" (in Scheme, Ruby, ...), and it gets around the
inconsistency that "augmented assignment" is often not assignment at
all.

> We could then say
>         big_matrix +! 3
> to save space and
>         integer_with_a_really_long_name += 3
> to save typing.

Yes. And someList += [3] could mean concatenate, then assign, as (IMO)
it should (which operation does not mutate any objects).


> > > Furthermore, in
> > >
> > >     a = []
> > >     b = a
> > >     a += [33]
> > >
> > > b changes. Neither "+" (list concatenation) nor "=" (assignment), would
> > > affect b at all.
> 
> If they did, we wouldn't need +=.

Well, we don't really "need" +=, since it doesn't enable anything we
couldn't do before. It's only a convenience.


> Wouldn't it be much harder to explain to newbies why
> x = [3]
> x += [4]
> Makes a copy of x?

I doubt any harder than explaining existing list concatenation, which
does exactly that. And "+" already means list concatenation -- why
introduce an additional meaning: "append"?

 
> You want the language to stay completely "clean" even though that hurts
> pragmatism.

But isn't it that what distinguishes Python from some other languages
such as Perl? I *like* Python's cleanness, and I don't want to lose it.


> It's *new*,
> dammit, it doesn't work exactly like you're used to, but that doesn't mean
> it can't be good. You're trying to make people's life harder for some ideal
> of cleanliness. In my opinion.

I agree that new doesn't mean it can't be good, but in this case, it
just isn't good. If it were old it still wouldn't be good  :-)

How much harder is it, by the way, to code

	lst.extend([33])	# meaning very clear
than
	lst += [33]		# less clear, but some think worth it


> Objects with mutable state generally
> *like* to have it mutated.  If you don't believe that, just ask the next
> mutable object you see!

Well, I did -- and lists replied that they like it so much they wonder
why the "+" operator doesn't already do it <wink>. If it did, then +=
wouldn't be inconsistent (but would be unnecessary). Why doesn't "+"
mutate lists? I don't really know, but I'd guess that it's because it's
not what we expect from established semantics of "+". It would be nice
to respect "=" in the same way.

Again, how about the existing suggestion of having a "mutation" compound
operator (+!). That would be only a slight change to the PEP. If Python
wants to offer a truly useful new innovation, that would be a much
better candidate! I wish I'd thought of that.

I'll still like Python if it keeps its current, awful definition of
augmented assignment. It will just have this nasty wart  :-)


> You seem to deeply dislike polymorphism...

I don't think this issue suggests any dislike of polymorphism. Such
powerful facilities require some discretion in their use. We don't
usually use polymorphism to cause the "+" operator to mean subtraction.
Similarly, we should be wary of redefining operators we call
"assignment" to mean something other than assignment.


Sorry for the repetition, but IMO the following would be really good, a
fairly minor change to the PEP, and better maintain the legendary
cleanliness of Python:

	x += y		always equivalent to x = x + y except that x is evaluated only
once
	x +! y		destructive operation that is similar to what "+" means
				(e.g., for lists, x.extend(y))


Bob