[Numpy-discussion] Array Protocol change for Python 2.6 (original) (raw)

David M. Cooke cookedm at physics.mcmaster.ca
Thu Jun 8 17:29:51 EDT 2006

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: > ... > arraystruct (perhaps we could call this arrayinterface 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 arraystruct is a CObject then it behaves as it does now. > > If arraystruct 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.arrayinterface.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 arraydata 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

More information about the NumPy-Discussion mailing list