[Numpy-discussion] The array interface published

[Scott Gilbert]

--- Magnus Lie Hetland <magnus at hetland.org> wrote:
>
> Why not just use 'shape' as an alias for '__array_shape__' (or vice
> versa)?
> 

The protocol just describes the layout and format of the data in memory. 
As such, most users won't use it directly just as most users don't call
obj.__add__ directly...

If an array implementation has a .shape attribute, it can be whatever the
implementor wants.  Perhaps it's assignable.  Maybe it's a method that
returns a ShapeObject with methods and attributes of it's own.  Features
like these are the things that make the high level array packages like
Numeric and Numarray enjoyable to use.  The low level __array_*metadata__
interface should be simple and precisely defined and just for data
interchange.


> 
> > 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 the support of these attributes is optional, that would have to be
> the case.
> 

> 
> As for implementing the defaults: How about having some utility
> functions (or a wrapper object or whatever) that does just this -- so
> neither array nor client code need think about it? This could,
> perhaps, be put in the stdlib array module or something...
> 

There will be a simple Python module or C include file for such things. 
Hopefully it will eventually be included in the Python standard
distribution, but even if that doesn't happen, it will be easier than
requiring and linking against the Numeric/Numarray/scipy.base libraries
directly.

> 
> But what I think would be cool if such a standardized package could
> take any object conforming to this protocol and use it (possibly as
> the argument to the array() constructor) -- with all the ufuncs and
> operators it has. Because then I could implement specialized arrays
> where the specialized behaviour lies just in the data itself, not the
> behaviour. For example, I might want to create a thin array wrapper
> around a memory-mapped, compressed video file, and treat it as a
> three-dimensional array of rgb triples... (And so forth.)
> 

If you want the ufuncs, you probably want one of the full featured library
packages like scipy.base or numarray.  It looks like Travis is able to
promote any "array protocol object" to a full blown scipy.base.array
already.


>
> > 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,
> 
> This does *not* sound like a good thing -- I agree. Certainly not what
> I would hope this protocol is used for.
> 

Things like argmax(x) are not part of this protocol.  The high level array
packages and libraries will have all sorts of crazy and useful features.

The protocol only describes the layout and format of the data.  It enables
higher level packages to work seemlessly with all the different array
objects. 

That said, this protocol would allow a version argmax(x) to be written in
such a way as to handle *any* array object.


Cheers,
    -Scott