[Numpy-discussion] Response to PEP suggestions

Travis Oliphant oliphant at ee.byu.edu
Sat Feb 19 13:20:26 EST 2005

>> Yes, but it could check for "integer type" (using the type 
>> hierarchy)  rather than convert everything to an integer with the 
>> problem that  Guido pointed out.
> Except that these types probably can't be derived from the builtin 
> int. The C layouts would have to be compatible. They'd probably have 
> to be a separate hierarchy.

On the python-dev list someone (Bob Ippolito) suggested inheriting 
rank-0 arrays from the Python Int Type.  I don't see how this can be 
even be done for all of the integer types (unless the Python Int Type is 
changed to hold the largest possible integer (long long)).   

> At that, rank-0 arrays would have to become a special case because 
> their value will have to be reflected by x->ob_ival. And how that 
> happens is going to depend on their actual C type. We'll be inheriting 
> methods that we can't use, and general arrays, even if the C types are 
> compatible, can't be used in place of a bona fide PyIntObject.
> I would prefer a single type of array object that can store different 
> kinds of values.

I see the same problems that Robert is talking about.  Do we really want 
to special-case all array code to handle rank-0 arrays differently?   
That seems to be opening up a very big can of worms.   Is the only way 
to solve this problem to handle rank-0 arrays in a separate hierarchy?  
I have doubts that such a system would even work.

> On the other hand, the list/tuple indexing issue won't go away until 
> the PEP is accepted and integrated into the core. And it won't be 
> accepted until Numeric3 has had some life of it's own outside the 
> standard library.

I agree with Robert's assesment --- bugger.  I'm really annoyed that 
such a relatively simple think like rank-0 arrays versus Python's 
already-defined scalars could be such a potential show-stopper.



More information about the NumPy-Discussion mailing list