[Numpy-discussion] The array interface published

[Michiel Jan Laurens de Hoon]

Travis Oliphant wrote:
>> 1) To what degree will the new array interface look different to users 
>> of the existing Numerical Python?
> 
> Nothing will look different.  For now there is nothing to "install" so 
> the array interface is just something to expect from other objects.    
> The only thing that would be different is in Numeric 24.0 (if a users 
> were to call array(<someobj>) and <someobj> supported the array 
> interface then Numeric could return an array (without copying data). 
> Older versions of Numeric won't benefit from the interface but won't be 
> harmed either.

Very nice. Thanks, Travis.
I'm not sure what you mean by "the array interface could become part of the 
Python standard as early as Python 2.5", since there is nothing to install. Or 
does this mean that Python's array will conform to the array interface?

Some comments on the array interface:

1) The "__array_shape__" method is identical to the existing "shape" method in 
Numerical Python and numarray (except that "shape" does a little bit better 
checking, but it can be added easily to "__array_shape__"). To avoid code 
duplication, it might be better to keep that method. (and rename the other 
methods for consistency, if desired).

2) The __array_datalen__ is introduced to get around the 32-bit int limitation 
of len(). Another option is to fix len() in Python itself, so that it can return 
  integers larger than 32 bits. So we can avoid adding a new method.

3) Where do default values come from? Is it the responsability of the extension 
module writer to find out if the array module implements e.g. __array_strides__, 
and substitute the default values if it doesn't? If so, I have a slight 
preference to make all methods required, since it's not a big effort to return 
the defaults, and there will be more extension modules than array packages (or 
so I hope).

Whereas the array interface certainly helps extension writers to create an 
extension module that works with all array implementations, it also enables and 
perhaps encourages the creation of different array modules, while our original 
goal was to create a single array module that satisfies the needs of both 
Numerical Python and numarray users. I still think such a solution would be 
preferable. Inconsistencies other than the array interface (e.g. one implements 
argmax(x) while another implements x.argmax()) may mean that an extension module 
can work with one array implementation but not with another, even though they 
both conform to the array interface. We may end up with several array packages 
(we already have Numerical Python, numarray, and scipy), and extension modules 
that work with one package and not with another. So in a sense, the array 
interface is letting the genie out of the bottle.

But maybe such a single array package is not attainable given the different 
needs of the different communities.

--Michiel.


-- 
Michiel de Hoon, Assistant Professor
University of Tokyo, Institute of Medical Science
Human Genome Center
4-6-1 Shirokane-dai, Minato-ku
Tokyo 108-8639
Japan
http://bonsai.ims.u-tokyo.ac.jp/~mdehoon