Augmented assignment should never modify the assign target!
Bob Alexander
balexander at rsv.ricoh.com
Fri Sep 8 15:21:49 EDT 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