[Numpy-discussion] Array Protocol change for Python 2.6
tim.hochberg at cox.net
Fri Jun 9 15:52:38 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.
I was going to say that it may help to think of array_interface as
returning a *view*, since that seems to be the semantics that could
probably be implemented safely without too much trouble. However, it
looks like that's not what happens. array_interface->shape and strides
point to the raw shape and strides for the array. That looks like it's a
>>> ai = a.__array_interface__
>>> a.shape = newshape
going to result in ai having a stale pointers to shape and strides that
no longer exist? Potentially resulting in a segfault? It seems the safe
approach is to give array_interface it's own shape and strides data. An
implementation shortcut could be to actually generate a new view in
array_struct_get and then pass that to PyCObject_FromVoidPtrAndDesc.
Thus the CObject would have the only handle to the new view and it
couldn't be corrupted.
More information about the NumPy-Discussion