[Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c

[Armin Rigo]

Hi,

On Mon, Mar 27, 2006 at 08:00:09PM -0800, Guido van Rossum wrote:
> So for consistency we want a += b to also execute a.__iadd__. The
> opcode calls PyNumber_InplaceAdd; I think that PyNumber_InplaceAdd
> (and PySequence_InplaceConcat, if it exists) should test for both the
> numeric and the sequence augmented slot of the left argument first;
> then they should try both the numeric and sequence non-augmented slot
> of the left argument; and then the numeric non-augmented slot of the
> right argument. Coercion should not be attempted at all.
> 
> The question is, can we do this in 2.5 without breaking backwards
> compatibility? Someone else with more time should look into the
> details of that.

I agree that there is a bug.  There is more than one inconsistency left
around here, though.  Fixing one might expose the next one...  For
example, if -- as the documention says -- the expression 'a + b' would
really try all slots corresponding to a.__add__(b) first and then fall
back only if the slots return NotImplemented, then we'd also have to fix
the following to return NotImplemented:

   >>> [].__add__(5)
   TypeError: can only concatenate list (not "int") to list

and then we have no place to put that nice error message.

Nevertheless I think we should fix all this for consistency.  I can try
to give it a good look.  I don't think many programs would break if the
change goes into 2.5, but there are some C extension modules out there
abusing the inner details of the type slots in unpredictable ways...


A bientot,

Armin