[Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
Travis E. Oliphant
oliphant.travis at ieee.org
Tue Mar 28 09:28:12 CEST 2006
More information about the Python-Dev mailing list
Tue Mar 28 09:28:12 CEST 2006
- Previous message: [Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
- Next message: [Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Greg Ewing wrote: > Travis E. Oliphant wrote: > >> I think this can be fixed easily by first checking the sequence slot for >> a sq_concat function before calling PyNumber_InPlaceAdd. > > However, if this *is* fixed, it looks like it's going to > break NumPy, in the sense that it will no longer be able > to force an arithmetic interpretation for "+" when adding > a sequence to an array. Well, it won't break any "documented" behavior of NumPy which does not use the sq_concat (or sq_concat_inplace) slot at all. I can't imaging anybody relying on an in-place operations to return a "different" object, but we could make the change and run all the NumPy/SciPy tests to see what happens. But, you are right that w = [1,2,3,4] w += array([1,2,3,4]) would no longer make w equal to array([2,4,6,8]). But, this seems like a very good thing to me, as such behavior is actually quite hard to explain except as "its a bug" -Travis
- Previous message: [Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
- Next message: [Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list