inconsistency with += between different types ?

Donn Cave donn at
Fri Aug 9 01:10:24 CEST 2002

Quoth huaiyu at (Huaiyu Zhu):
| Donn Cave <donn at> wrote:
(quoting yourself)
|>| Once that's done, the documentation could be as simple as:
|>|   If __iadd__ is defined, x+=y changes x in place as per x.__iadd__(y).
|>|   Otherwise x+=y has a semantics similar x=x+y, except that x is only
|>|   evaluated once.
|>| In contrast, I'd challenge anyone to explain the current += behavior in less
|>| than twice that many words without misleading casual readers.
|> But that isn't really the best documentation either.  I mean,
|> what if we document x + y as ``whatever x.__add__(y) may do?''
|> Somehow you need to define under what circumstances you would
|> expect one behavior, vs. the other.  If you retreat to the
|> implementation for that, then you're saying you don't know unless
|> you're familiar with the implementation - does it have __iadd__
|> or not?  May as well require you to know what __iadd__ does.
| I don't quite follow you here.  

Well, my point is that += has two different possible types of result,
and if you want to know which to expect for a particular object, we
have no very good answer.  If you need to know whether __iadd__ exists
or not, then we're asking you to look much farther into its internal
implementation than ought to be normally necessary.  From there, I
don't think it's much worse to require you to determine what __iadd__
does - that's more work, but there's a certain logic to it too.
The improvement is not so great that it's worth changing behavior.

Your proposal to divide += into two operations is more attractive.
I'd keep the modify-in-place semantics, and spell the rebinding
operation =...+  -- as in, x = x + y.

	Donn Cave, donn at

More information about the Python-list mailing list