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