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

[Tim Hochberg]

Travis Oliphant wrote:

>
>> 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).

I'll look these over. I suppose I should have been paying more attention 
before!

>>
>>    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.

Mainly because I didn't want too much about whether a given method or 
attribute was a good idea and I was in a hurry when I tossed that 
proposal out. It seemed better to start with the most stripped down 
proposal I could come up and see what people demanded I add.. I'm 
actually sort of inclined to give it *read-only* attribute associated 
with C-structure, but no methods. That way you can examine the shape, 
type, etc but you can't set them [I'm specifically thinking of shape 
here, but there may be others].. I think that there are cases where you 
don't want the base array to be mutable at all, but I don't think 
introspection should be a problem. If the attributes were setabble, you 
could always override the them with readonly properties, but it'd be 
cleaner to just start with readonly functionality and add setability (is 
that a word?) only in those cases where it's needed.

>
>>        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?

Good point.

>
>>        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.
>
Hmm. This idea seems to have a fair bit of consensus behind it. I guess 
that means I better looking into exactly what it would take to make it 
work. The details of what attributes to expose, etc are probably not too 
important to work out immediately.

Regards,

-tim