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

[Guido van Rossum]

On 3/28/06, Armin Rigo <arigo at tunes.org> wrote:
> 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...

Thanks for looking into this!

C extensions are my main worry -- OTOH if += for a list can already
passes arbitrary types as the argument, then any extension types
should be ready to expect this, right?

--
--Guido van Rossum (home page: http://www.python.org/~guido/)