[Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c (original) (raw)

Armin Rigo arigo at tunes.org
Tue Mar 28 13:28:56 CEST 2006

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 PyNumberInplaceAdd; I think that PyNumberInplaceAdd (and PySequenceInplaceConcat, 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

More information about the Python-Dev mailing list