inconsistency with += between different types ?

Huaiyu Zhu huaiyu at gauss.almadan.ibm.com
Fri Aug 9 02:31:45 CEST 2002


Donn Cave <donn at u.washington.edu> wrote:
>
>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.

OK, I get your point.  Just for nitpicking, you can use
hasattr(a,'__iadd__') to test its existence.  So it's not completely
internal implementation.  On the other hand, I don't know of a way to
ask what it returns without looking into the code.  (Theoretically it is
generally impossible to know what it returns even when you _can_ look
into the code, though that has no bearing on the actual usage.)

>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.

The two rebindings are not the same, either.  For example, x could be
a[2]['adsf'].something.  Writing it twice could trigger all the magic
mothods twice.  It's tricky to do it right using temporary variables.
IMO that's the practical use of the assignment semantics (instead of
saving keystrokes).  Though I still think it's a bad idea to use the
same symbol for these two different semantics.

Huaiyu



More information about the Python-list mailing list