inconsistency with += between different types ?
Donn Cave
donn at u.washington.edu
Thu Aug 8 19:10:24 EDT 2002
Quoth huaiyu at gauss.almadan.ibm.com (Huaiyu Zhu):
| Donn Cave <donn at u.washington.edu> 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 u.washington.edu
More information about the Python-list
mailing list