[Numpy-discussion] Array Protocol change for Python 2.6

[Alexander Belopolsky]

On 6/9/06, Travis Oliphant <oliphant at ee.byu.edu> wrote:
> ...   In NumPy this is not quite the rule followed.
> Bascially attributes are used when getting or setting intrinsinc
> "properties" of the array.  Attributes are used for properties that are
> important in defining what an array *is*.   The flags attribute, for
> example, is an important intrinsinc property of the array but it returns
> an flags object when it is accessed.   The flat attribute also returns a
> new object (it is arguable whether it should have been a method or an
> attribute but it is enough of an intrinsic property --- setting the flat
> attribute sets elements of the array -- that with historical precedence
> it was left as an attribute).
>
> By this meausure,  the array interface should be an attribute.
>

Array interface is not an intrinsic property of the array, but rather
an alternative  representation of the array itself.

Flags are properly an attribute because they are settable.  Something like

>>> x.flags()['WRITEABLE'] = False

although technically possible, would be quite ugly.

Similarly, shape attribute,  although fails my rule of thumb by
creating a new object,

>>> x.shape is x.shape
False

is justifiably an attribute because otherwise two methods: get_shape
and set_shape would be required.

I don't think "flat" should be an attribute, however.   I could not
find the reference, but I remember a discussion of why __iter__ should
not be an attribute and IIRC the answer was because an iterator has a
mutable state that is not reflected in the underlying object:

>>> x = arange(5)
>>> i = x.flat
>>> list(i)
[0, 1, 2, 3, 4]
>>> list(i)
[]
>>> list(x.flat)
[0, 1, 2, 3, 4]

> >> My problem with __array_struct__ returning either a tuple or a CObject
> >> is that array protocol sholuld really provide both.
> >
> This is a convincing argument.   Yes, the array protocol should provide
> both.  Thus, we can't over-ride the usage of the same name unless that
> name produces an object through which both interfaces can be obtained.
>
> Is that Sasha's suggestion?
>
It was, but I quckly retracted it in favor of a mechanism to unpack the CObject.
FWIW, I am also now -0 on the name change from __array_struct__ to
__array_interface__ if what it provides is just a struct wrapped in a
CObject.