[Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
Guido van Rossum
guido at python.org
Tue Mar 28 19:50:49 CEST 2006
On 3/28/06, Armin Rigo <arigo at tunes.org> wrote:
> 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/)
More information about the Python-Dev