var or inout parm?

[Hrvoje Niksic]

Marc 'BlackJack' Rintsch <bj_666 at 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.