[Numpy-discussion] Response to PEP suggestions
Travis Oliphant
oliphant at ee.byu.edu
Sat Feb 19 13:20:26 CST 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.
Hoping-it-won't-be
-Travis
More information about the Numpy-discussion
mailing list