[Numpy-discussion] Array Protocol change for Python 2.6

Alexander Belopolsky alexander.belopolsky at gmail.com
Fri Jun 9 14:55:07 EDT 2006

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

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

More information about the NumPy-Discussion mailing list