--- Magnus Lie Hetland <magnus@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