[Numpy-discussion] Array Protocol change for Python 2.6

[Sasha]

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
<http://mail.python.org/pipermail/python-3000/2006-April/000362.html>.

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

My metaclass idea is very similar to your unpack_interface suggestion.
 A metaclass can autonatically add

def __array_tuple__(self):
    return unpack_interface(self.__array_interface__())


or

def __array_interface__(self):
    return pack_interface(self.__array_tuple__())

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.