C basetype problem, works on 2.3, not on 2.2.1

[Todd Miller]

  I am trying to add C basetypes to numarray to accelerate basic 
indexing operations and frequently used methods.

The Python-2.2 design of numarray looks like:

object
<-- NDArray # Python structural arrays defining indexing and reshaping 
operations
<-- NumArray # Python numeric arrays defining the number protocol

I am trying to accelerate it by changing it to:

_ndarray # C basetype caching NDArray attributes and accelerating simple 
mappings
<-- NDArray # Python structural arrays defining indexing and reshaping 
operations
<-- NumArray # Python numeric arrays defining the number protocol

I have something that appears to work with Python-2.3 CVS. However, in 
Python-2.2.1, I see the following:

 >>> import numarray
 >>> a=numarray.arange(10)
 >>> a
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/home/jmiller/lib/python2.2/site-packages/numarray/numarray.py", 
line 622, in __repr__
MAX_LINE_WIDTH, PRECISION, SUPPRESS_SMALL, ', ', 1)
File "/home/jmiller/lib/python2.2/site-packages/numarray/arrayprint.py", 
line 156, in array2string
separator, array_output)
File "/home/jmiller/lib/python2.2/site-packages/numarray/arrayprint.py", 
line 112, in _array2string
max_str_len = max(len(str(max_reduce(data))),
File "/home/jmiller/lib/python2.2/site-packages/numarray/ufunc.py", line 
759, in reduce
r = self.areduce(inarr, dim, outarr)
File "/home/jmiller/lib/python2.2/site-packages/numarray/ufunc.py", line 
745, in areduce
_outarr1 = self._cumulative("reduce", _inarr, _outarr0)
File "/home/jmiller/lib/python2.2/site-packages/numarray/ufunc.py", line 
653, in _cumulative
toutarr = self._reduce_out(inarr, outarr, outtype)
File "/home/jmiller/lib/python2.2/site-packages/numarray/ufunc.py", line 
591, in _reduce_out
toutarr = inarr[...,0].copy().astype(outtype)
TypeError: an integer is required

The problem is with the expression "inarr[...,0]". Hacking up 
Python-2.2.1's intobject.c to abort rather than raise an exception, and 
running my hacked Python under GDB, I get:

 >>> a=numarray.arange(10)
 >>> a

Program received signal SIGABRT, Aborted.
[Switching to Thread 1024 (LWP 14948)]
0x42029331 in kill () from /lib/i686/libc.so.6
(gdb) where
#0 0x42029331 in kill () from /lib/i686/libc.so.6
#1 0x40031c4b in raise () from /lib/i686/libpthread.so.0
#2 0x4202a8c2 in abort () from /lib/i686/libc.so.6
#3 0x080b9d7d in PyInt_AsLong (op=0x81a58e4) at Objects/intobject.c:158
#4 0x0806604e in wrap_sq_item (self=0x826256c, args=0x81a752c, 
wrapped=0x4006e1a4) at Objects/typeobject.c:2297
#5 0x080b32fa in wrapper_call (wp=0x8187e04, args=0x81a752c, kwds=0x0) 
at Objects/descrobject.c:819
#6 0x080a71a4 in PyObject_Call (func=0x8187e04, arg=0x81a752c, kw=0x0) 
at Objects/abstract.c:1684
#7 0x0805ec22 in call_method (o=0x826256c, name=0x80cfa55 "__getitem__", 
nameobj=0x80fa418, format=0x80ccee6 "(O)")
at Objects/typeobject.c:510
#8 0x080669d8 in slot_mp_subscript (self=0x826256c, arg1=0x81a58e4) at 
Objects/typeobject.c:2890
#9 0x080a4c94 in PyObject_GetItem (o=0x826256c, key=0x81a58e4) at 
Objects/abstract.c:95
#10 0x08074fd4 in eval_frame (f=0x817b35c) at Python/ceval.c:1024
#11 0x08077c83 in PyEval_EvalCodeEx (co=0x81e2b20, globals=0x81eed0c, 
locals=0x0, args=0x826292c, argcount=4, kws=0x826293c, kwcount=0, 
defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585

<massive-snip>

Popping up a few levels in the stack with gdb, I see something 
perplexing about the array being subscripted:

(gdb) p *self->ob_type->tp_as_mapping
$2 = {mp_length = 0x4006eb7c <_ndarray_length>, mp_subscript = 0x80669b8 
<slot_mp_subscript>,
mp_ass_subscript = 0x80669e0 <slot_mp_ass_subscript>}

Somehow, part of the mapping protocol is being overridden, but part is 
not. Since _ndarray defines all of the mapping protocol and NDArray does 
not define __getitem__ or __setitem__, I don't see why the generic 
wrapper, slot_mp_subscript, is being called. Also, it appears that it is 
*not* called in 2.3.

Help?

Todd

-- 
Todd Miller 			jmiller at stsci.edu
STSCI / SSG