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

Tim Hochberg tim.hochberg at cox.net
Fri Jun 9 12:04:09 EDT 2006

Sasha wrote:

On 6/8/06, David M. Cooke <cookedm at physics.mcmaster.ca> wrote:

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

My rule of thumb for choosing between an attribute and a method is that attribute access should not create new objects. Conceptually at least, couldn't there be a single array_interface object associated with a given array? In that sense, it doesn't really feel like creating a new object.

In addition, to me arrayinterface feels like a generalization of array method, so I personally expected it to be a method the first time I tried to use it.

... 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.

Not necessarily. Different packages don't need to share the subclass, but subclassing CObject is probably a bad idea for the reasons I will explain below. 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). My problem with arraystruct returning either a tuple or a CObject is that array protocol sholuld really provide both. CObject is useless for interoperability at python level and a tuple (or dict) is inefficient at the C level. Thus a good array-like object should really provide both arraystruct for use by C modules and arraytuple (or whatever) for use by python modules. On the other hand, making both required attributes/methods will put an extra burden on package writers. Moreover, a pure python implementation of an array-like object will not be able to provide arraystruct at all. One possible solution would be an array protocol metaclass that adds arraystruct_ to a class with arraytuple and _arraytuple to a class with arraystruct (yet another argument to make both methods). I don't understand this. I'm don't see how bringing in metaclass is going to help a pure python type provide a sensible array_struct. That seems like a hopeless task. Shouldn't pure python implementations just provide array?

A single attribute seems pretty appealing to me, I'm don't see much use for anything else.

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

What do you have in mind? Is there any prospect of merging this data into the C struct? It would be cleaner if all of the information could be embedded into the C struct, but I can see how that might be a backward compatibility nightmare.

-tim

Numpy-discussion mailing list Numpy-discussion at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion

More information about the NumPy-Discussion mailing list