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

Tim Hochberg tim.hochberg at cox.net
Fri Jun 9 13:54:36 EDT 2006

Sasha wrote:

On 6/9/06, Tim Hochberg <tim.hochberg at cox.net> wrote:

Sasha wrote: ...

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 arrayinterface object associated with a given array? In that sense, it doesn't really feel like creating a new object. In my view, conceptually, arrayinterface creates a adaptor to the array-like object. What are the advantages of it being an attribute? It is never settable, so the most common advantage of packing get/set methods in a single attribute can be rulled out. Saving typing of '()' cannot be taken seriousely when the name contains a pair of double underscores :-). There was a similar issue discussed on the python-3000 mailing list with respect to hash method <http://mail.python.org/pipermail/python-3000/2006-April/000362.html>. Isn't array_interface always O(1)? By the criteria in that thread, that would make is good candidate for being an attribute.

[Stare at array_interface spec...think..stare...]

OK, I think I'm coming around to making it a function. Presumably, in:

a = arange(6) ai1 = a.array_interface() a.shape = [3, 2] ai2 = a.array_interface()

ai1 and ai2 will be different objects with different objects, pointing to structs with different shape and stride attributes. So, in that sense it's not conceptually constant and should be a function.

What happens if I then delete or resize a? Hmmm. It looks like that's probably OK since CObject grabs a reference to a.

FWIW, at this point, I marginally prefer array_struct to array_interface.

....

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 arraystruct. That seems like a hopeless task. Shouldn't pure python implementations just provide array? My metaclass idea is very similar to your unpackinterface suggestion. A metaclass can autonatically add def arraytuple(self): return unpackinterface(self.arrayinterface()) or def arrayinterface(self): return packinterface(self.arraytuple()) to a class that only implements only one of the two required methods. It seems like 99% of the people will never care about this at the Python level, so adding an extra attribute is mostly clutter. For those few who do care a function seems preferable. To be honest, I don't actually see a need for anything other than the basic array_struct.

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

I don't mind just having arraystruct that must return a CObject. My main objection was against a method/attribute that may return either CObject or something else. That felt like shifting the burden from package writer to the package user. I concur.

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