There has been a lengthe thread over the semantics of __iadd__ a few
weeks ago. It _can_ modify the object in question in-place (something
not possible for ints anyway), but it will ALWAYS return a reference
which will be set to the left-hand-side.
Thanks! I'd missed that thread, googling found it but it didn't look
noteworthy at first glance. I've not yet read the entire thread, but
I did see a reference to PEP 203.
) So, given the expression:
)
) x += y
)
) The object `x' is loaded, then `y' is added to it, and the
) resulting object is stored back in the original place.
That agrees with what I'm seeing, all right. The problem is, the
resulting object has a different type, which seems to violate the
spirit of a later paragraph:
) Writing the above expression as
)
) <x> <operator>= <y>
)
) is both more readable and less error prone, because it is
) instantly obvious to the reader that it is <x> that is being
) changed, and not <x> that is being replaced by something almost,
) but not quite, entirely unlike <x>.
And that's my complaint. The value in <zed> is being replaced by
something almost, but not quite, identical to the original value.
Python's internal implementation of __iadd__ for <int> isn't returning
<self>, it's returning a new value belonging to the super-class. My
whole point is overloading <int> was that I'd hoped to avoid having to
write a bunch of methods to perform in-place modifications. Looks
like I stuck, however.