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

Armin Rigo arigo at tunes.org
Thu Mar 30 09:56:00 CEST 2006


Hi Tim,

Oups, sorry.  I only just realized my mistake and the meaning of your
message.

On Thu, Mar 30, 2006 at 09:27:02AM +0200, Armin Rigo wrote:
>     >>> t = (1,2,3)
>     >>> t += [4,5,6]
>     TypeError: can only concatenate tuple (not "list") to tuple
> 
>     >>> t += array([4,5,6])
>     TypeError: ...
> 
> This is current behavior and it wouldn't change.

I'm pasting untested bits of code.  Indeed, as you point out:

    >>> t = (1,2,3)
    >>> t += array([4,5,6])
    >>> t
    array([5, 7, 9])

and it would remain so after the fix.  I still think the fix is a good
thing, and the above is an issue at a different level.  It's somehow the
"fault" of list.__iadd__ and list.__imul__, which are oddballs -- before
the introduction of set objects, it was the single place in the whole
library of built-in types where in-place behavior was different from
normal behavior.

It would require an official language extension to say that for all
sequences, += is supposed to accept any iterable (which may or may not
be a good thing, I have no opinion here).

Otherwise, I'd just ignore the whole sub-issue, given that 'tuple +=
array' returning an array is just correct language-wise and doesn't look
like a trap for bad surprises -- if the user expected a tuple but gets
an array, most tuple-like operations will work just fine on the array,
except hashing, which gives a clean TypeError.


A bientot,

Armin


More information about the Python-Dev mailing list