Marc 'BlackJack' Rintsch <bj_...@gmx.net> writes:
> On Sat, 13 Dec 2008 02:20:59 +0100, Hrvoje Niksic wrote:
>
>> Saner (in this respect) behavior in the tuple example would require
>> a different protocol. I don't understand why Python doesn't just
>> call __iadd__ for side effect if it exists. The decision to also
>> rebind the result of __i*__ methods continues to baffle me. I
>> guess it is a result of a desire to enable the __i*__ methods to
>> punt and return a different instance after all, but if so, that
>> design decision brings more problems than benefits.
>
> How often do you use ``+=`` with mutable objects? I use it very
> often with number types and sometimes with tuples, and there
> rebinding is necessary. If I couldn't use it in this way: ``x = 0;
> x += z``, I'd call that a bad design decision. It would be a quite
> useless operator then.
Marc, I agree with you, I wasn't arguing that += shouldn't work for
immutable objects. If an object doesn't support __iadd__ at all (as
is already the case for numbers, strings, etc.), += should fall back
to __add__ followed by assignment. My point is that, *if they do*, it
would be better to just use __iadd__ and not attempt to also rebind.
Again, in pseudocode, I'd expect A += x to be implemented as:
lhsobj = A
if hasattr(lhsobj, '__iadd__'):
lhsobj.__iadd__(x) # lhsobj has __iadd__, just use it
else:
A = lhsobj.__add__(x) # fails if __add__ is not present either
That way tupleobj[0] += blah would work just fine for mutable objects
and would throw an exception for immutable objects. The current
situation where += first modifies the mutable object, and *then*
throws an exception feels like a design glitch.
--
http://mail.python.org/mailman/listinfo/python-list
