[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