At 04:16 PM 10/25/03 -0700, Guido van Rossum wrote:
No way. There's nothing that guarantees that a+=b has the same semantics as a+b, and in fact for lists it doesn't.
You mean because += is more permissive (accepts any sequence RHS while + insists the RHS be specifically a list)? I don't see how this would make it bad to use += instead of + -- if we let the user sum up a mix of (e.g.) strings and tuples, why are we hurting him?
We specifically decided that sum() wasn't allowed for strings, because it's a quadratic algorithm. Other sequences are just as bad, we just didn't expect that to be a common case.
Also see my not-so-far-fetched example of a semantic change.
Maybe I'm confused, but when Alex first proposed this change, I mentally assumed that he meant he would change it so that the *first* addition would use + (in order to ensure getting a "fresh" object) and then subsequent additions would use +=. If this were the approach taken, it seems to me that there could not be any semantic change or side-effects for types that have compatible meaning for + and += (i.e. += is an in-place version of +). Maybe I'm missing something here?