[Numpy-discussion] Array Protocol change for Python 2.6 (original) (raw)

Tim Hochberg tim.hochberg at cox.net
Fri Jun 9 15:52:38 EDT 2006

Sasha wrote:

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 problem. Isn't:

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.

[SNIP]

-tim

More information about the NumPy-Discussion mailing list