Augmented assignment should never modify the assign target!

Bob Alexander balexander at rsv.ricoh.com
Fri Sep 8 21:21:49 CEST 2000


Bjorn Pettersen wrote:
> 
> Bob Alexander wrote:
> >
> >         target += value
> >
> > is always equivalent to
> >
> >         target = target + value
> >
> > period!
> [snip]
> 
> I think that would be a _really_ bad idea <wink>.  One of the reasons to
> include augmented assignment was to decrease the memory burden on
> in-place operations. Yes, you can do that with a method, but this was
> also added since it's more natural to say "add value to target" than
> "add value and target together and bind the result to target". It's such
> a common idiom that it's worth having both special syntax and shortcut
> semantics for it.

But, modifying an object shouldn't be the job of the assignment
operation.

If modifying the original object assigned to list1 is natural in the
statement

	list1 += list2

then the expression

	list1 + list2

should modify list1, too.

As it is, one has to memorize semantics for each binary operator PLUS
the semantics for each augmented assignment operator, since they are
inconsistent. If the consistent definition were that a += b === a = a +
b, ALWAYS, it would make life a bit simpler, and simple is good when it
comes to programming languages. Augmented assignment is extremely useful
without having mutating versions (as demonstrated by C, Java, Icon,
etc.) -- it's just not necessary or desirable to add the extra
conceptual complication. Using methods to mutate objects is preferable,
in my opinion.

The current definition is something I'd more expect to see in Perl,
where impure semantics are the norm.

> -- bjorn

Bob




More information about the Python-list mailing list