On Sunday 26 October 2003 04:41 pm, Phillip J. Eby wrote: > 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. ... > 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 +=. A better architecture than the initial copy.copy I was now thinking of -- thanks. But it doesn't solve Guido's objection as above shown. > 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? Only the fact that "there's nothing that guarantees" this, as Guido says. alist = alist + x only succeds if x is also a list, while alist += x succeeds also for tuples and other sequences, for example. Personally, I don't think this would be a problem, but it's not my decision. Alex
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