[Numpy-discussion] Re: ndarray.fill and ma.array.filled

[Travis Oliphant]

> This may be an oportune time to propose something that's been cooking 
> in the back of my head for a week or so now: A stripped down array 
> superclass. The details of this are not at all locked down, but here's 
> a strawman proposal.

This is in essence what I've been proposing since SciPy 2005.  I want 
what goes into Python to be essentially just this super-class. 

Look at this http://numeric.scipy.org/array_interface.html

and check out this

svn co http://svn.scipy.org/svn/PEP arrayPEP

I've obviously been way over-booked to do this myself.    Nick Coughlan 
expressed interest in this idea (he called it dimarray, but I like 
basearray better). 

>
>    We add an array superclass. call it basearray, that has the same
>    C-structure as the existing ndarray. However, it has *no* methods or
>    attributes. 

Why not give it the attributes corresponding to it's C-structure.  I'm 
happy with no methods though.

>        1. If we're careful, this could be the basic array object that
>    we propose, at least for the first roun,d for inclusion in the
>    Python core. It's not useful for anything but passing data betwen
>    various application that understand the data structure, but that in
>    itself could be a huge win. And the fact that it's dirt simple would
>    probably be an advantage to getting it into the core.

The only extra thing I'm proposing is to add the data-descriptor object 
into the Python core as well --- other-wise what do you do with  
PyArray_Descr * part of the C-structure?

>        2. It provides a useful marker class. MA could inherit from it
>    (and use itself for it's data attribute) and then asanyarray would
>    behave properly. MA could also use this, or a subclass, as the mask
>    object preventing anyone from accidentally using it as data (they
>    could always use it on purpose with asarray).

>        3. It provides a platform for people to build other,
>    ndarray-like classes in Pure python. This is my main interest. I've
>    put together a thin shell over numpy that strips it down to it's
>    abolute essentials including a stripped down version of ndarray that
>    removes most of the methods. All of the __array_wrap__[1] stuff
>    works quite well most of the time, but there's still some issues
>    with being a subclass when this particular class is conceptually a
>    superclass. If we had an array superclass of some sort, I believe
>    that these would be resolved.
>
> In principle at least, this shouldn't be that hard. I think it should 
> mostly be rearanging some code and adding some wrappers to existing 
> functions. That's in principle. In practice, I'm not certain yet as I 
> haven't investigated the code in question in much depth yet. I've been 
> meaning to write this up into a more fleshed out proposal, but I got 
> distracted by the whole Protocol discussion on python-dev3000. This 
> writeup is pretty weak, but hopefully you get the idea.

This is exactly what needs to be done to improve array-support in 
Python.  This is the conclusion I came to and I'm glad to see that Tim 
is now basically having the same conclusion.   There are obviously some 
details to work out.   But, having a base structure to inherit from 
would be perfect.

-Travis