[Numpy-discussion] Array Protocol change for Python 2.6

[David M. Cooke]

On Thu, 8 Jun 2006 17:07:55 -0400
Sasha <ndarray at mac.com> wrote:

> On 6/8/06, Travis Oliphant <oliphant at ee.byu.edu> wrote:
> > ...
> > __array_struct__   (perhaps we could call this __array_interface__ but
> > I'm happy keeping the name the same too.)
> 
> +0 on the name change and consider making it a method rather than an
> attribute.

+0 for name change; I'm happy with it as an attribute.

> > If __array_struct__ is a CObject then it behaves as it does now.
> >
> > If __array_struct__ is a tuple then each entry in the tuple is one of
> > the items currently obtained by an additional attribute access (except
> > the first item is always an integer indicating the version of the
> > protocol --- unused entries are None).
> >
> 
> -1
> 
> This will complicate the use of array interface.  I would propose
> creating a subtype of CObject that has the necessary attributes so
> that one can do a.__array_interface__.shape, for example.  I did not
> check if CObject is subclassable in 2.5, but if not, we can propose to
> make it subclassable for 2.6.

The idea behind the array interface was to have 0 external dependencies: any
array-like object from any package could add the interface, without requiring
a 3rd-party module. That's why the C version uses a CObject. Subclasses of
CObject start getting into 3rd-party requirements.

How about a dict instead of a tuple? With keys matching the attributes it's
replacing: "shapes", "typestr", "descr", "data", "strides", "mask", and
"offset". The problem with a tuple from my point of view is I can never
remember which order things go (this is why in the standard library the
result of os.stat() and time.localtime() are now "tuple-like" classes with
attributes).

We still need __array_descr__, as the C struct doesn't provide all the info
that this does.

> > I would like to eliminate all the other array protocol attributes before
> > NumPy 1.0 (and re-label those such as __array_data__ that are useful in
> > other contexts --- like ctypes).
> +1

+1 also

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca