[Numpy-discussion] Array Protocol change for Python 2.6

[Sasha]

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.  In addition, to
me __array_interface__ 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 __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).


> We still need __array_descr__, as the C struct doesn't provide all the info
> that this does.
>
What do you have in mind?