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?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4