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

Tim Hochberg tim.hochberg at cox.net
Mon Apr 10 16:09:03 CDT 2006

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 

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



More information about the Numpy-discussion mailing list