[SciPy-dev] Nested arrays

Travis Oliphant oliphant.travis at ieee.org
Tue Jan 10 19:12:38 CST 2006

Sasha wrote:
> "Always being able to get the .shape attribute" is a nice feature and
> I would rather
> not loose it without a compelling reason.  Note that making ndarray a
> valid dtype
> will not have an effect of a[i] loosing array API because ndarrays
> already have it by
> definition.  For objects that don't have their own array interface one
> can entertain an
> idea of creating a scalar class dynamically that inherits from the
> type of the object and
> mixes in array API using muliple inheritance or some metaclass magic.

We can also special-case the object-array typeobject so that we pass off 
all behavior in the function table to the underlying object.  This is 
what I did, for example, to support attribute getting and setting.

It would be a straightforward thing to do it as well for the other 
function pointers in the type-object table.  Asking whether the object 
is a sub-class of a certain type would certainly fail still (although 
there may be a work around for this if we use a different meta-class).

> Making ndarray a valid dtype will also allow constructing arrays from
> ragged lists

Originally an ndarray was a valid dtype, but it was removed to help in 
detecting the common error

zeros(3,4)  when you mean zeros((3,4))

of course the use-case would be


where dim2 was an ndarray that should be interpreted as an integer.

I suppose, that because ndarray is now a valid data-type as a 
typeobject, then we could easily special case it to make it more meaningful.


More information about the Scipy-dev mailing list