[Numpy-discussion] Array Protocol change for Python 2.6
ndarray at mac.com
Fri Jun 9 11:50:16 CDT 2006
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 __array_interface__
> object associated with a given array? In that sense, it doesn't really
> feel like creating a new object.
In my view, conceptually, __array_interface__ 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
> >My problem with __array_struct__ 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 __array_struct__ for use by C modules and
> >__array_tuple__ (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 __array_struct__ at all.
> > One possible solution would be an array protocol metaclass that adds
> >__array_struct__ to a class with __array_tuple__ and __array_tuple__
> >to a class with __array_struct__ (yet another argument to make both
> 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__?
My metaclass idea is very similar to your unpack_interface suggestion.
A metaclass can autonatically add
to a class that only implements only one of the two required methods.
> A single attribute seems pretty appealing to me, I'm don't see much use
> for anything else.
I don't mind just having __array_struct__ 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.
More information about the Numpy-discussion