Behavior of += (was Re: [Python-Dev] Customization docs)
donn at u.washington.edu
Tue Jun 4 23:35:34 CEST 2002
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
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
Donn Cave, donn at u.washington.edu
More information about the Python-list