Behavior of += (was Re: [Python-Dev] Customization docs)

[Donn Cave]

Quoth "Steve Holden" <sholden at holdenweb.com>:
| "Donn Cave" <donn at u.washington.edu> wrote ...
...
|> Not really - the current semantics are actually better than the fixed
|> version, inasmuch as they are at least consistent.  As I interpret the
|> proposal, the fixed += would sometimes work without rebinding (if the
|> object supports it) and sometimes would be an assignment (falling back
|> to +.)  To me, to allow an object to dictate its relationship to its
|> computational environment like that is anathema.
|
| >>> a = b = (1, 2, 3)
| >>> a += ('boo!',)
| >>> a, b
| ((1, 2, 3, 'boo!'), (1, 2, 3))
| >>> a = b = [1, 2, 3]
| >>> a += ['boo!']
| >>> a, b
| ([1, 2, 3, 'boo!'], [1, 2, 3, 'boo!'])
|
| Doesn't look that consistent to me. Add in the fact that implementors of
| mutable objects are free to choose either semantic and what you have is ...
| exactly what Guido intended. I regard it as a wart, but not one that worried
| me.

Well, it is consistent.  Maybe not in a way that you can see
and still remain sane.  "Mutable" or not, it must always work
like "a = iadd(a, b)", where iadd attempts to perform some
computation like __iadd__() or eventually "+".  The fact that
__iadd__ may return any imaginable value is no queerer than
the same fact about __add__.

I'm not saying it's good, on the contrary, it's terrible.  I just
don't think it sounds very good to fix it by changing the rules
so it sometimes means the above, and sometimes omits the assignment.
As long as it has to work on values that don't support it as a
mutating __iadd__ or equivalent, it should probably stay the way
it is.

	Donn Cave, donn at u.washington.edu