
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