> > 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.
In the context of sum(), I think it would be nice to allow iterables to
be added together: sum(['abc', range(3), ('do', 're', 'me')], [])
This fits in well with the current thinking that the prohibition of
adding sequences of unlike types be imposed only on operators and not on
functions or methods. For instance, in sets.py, a|b requires both a and
b to be Sets; however, a.union(b) allows b to be any iterable. The
matches the distinction between list.__iadd__() and list.extend() where
the former requires a list argument and the latter does not.
Raymond Hettinger
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