inconsistency with += between different types ?

[Steve Holden]

"Andreas Leitgeb" <Andreas.Leitgeb at siemens.at> wrote ...
> Huaiyu Zhu <huaiyu at gauss.almadan.ibm.com> wrote:
> > That's what it should be.  Yet it is possible for whoever writes
__iadd__ to
> > define it the other way.
> Really ?
>
Yes, really.

> Inside __iadd__ I've got the "self"-parameter:
>  If I assign directly to "self", then it won't have any effect outside
>    the method.
Indeed, as "self" is simply a local variable containing a reference to the
object.

>  If I assign to self.whatever, I mutate the object in place.

Yes.

> Is there something I've missed, or does it indeed boil down to
>  defining or not defining __ixxx__ ?
>
Yes. Implementors can choose *not* to implemenbt __ixxx__, in which case the
augmented assignment operators are emulated using their traditional
counterparts.

> Also, what characterizes an object to be mutable ?
> Is it the existence or not-existence of mutating methods, or
>  is the more behind the scenes of strings,ints and tuples ?
>
Section 3.1 of the Reference Manual defines mutability (in so far as an
adequate definition is given). Section 6.3 says """When a target is part of
a mutable object (an attribute reference, subscription or slicing), the
mutable object must ultimately perform the assignment and decide about its
validity, and may raise an exception if the assignment is unacceptable."""

> > Consider this table:
> >                 in place         assignment
> >             +---------------+----------------+
> > mutable     |       A       |        B       |
> >             +---------------+----------------+
> > immutable   |       C       |        D       |
> >             +---------------+----------------+
> How I understand it:  (and it looks quite reasonable that way)
> (__iadd__ stands for all the __i...__-methods)
> A: __iadd__ is defined
> B: only __add__ is defined, not __iadd__
> C: hmm, if __iadd__ is defined, then "per definition" the object
>      is not immutable, thus not C :-)
> D: neither __iadd__ nor any other mutating method is defined,
>      but __add__ is.
>
> > Consequently we are seeing frequent questions on this issue.
> If it actually works the way, I now think it does, then it's just
> a lack of clear documentation.
>
The current documentation is indeed a little misleading: """Also, when
possible, the actual operation is performed in-place, meaning that rather
than creating a new object and assigning that to the target, the old object
is modified instead""".

Would it be better as """Also, at the discretion of the implementor,
augmented assignments on mutable objects can be performed in-pace, meaning
that rather than creating a new object ..."""?

otherwise-rewrite-in-your-own-words-ly y'rs  - steve
-----------------------------------------------------------------------
Steve Holden                                 http://www.holdenweb.com/
Python Web Programming                http://pydish.holdenweb.com/pwp/
-----------------------------------------------------------------------