[Numpy-discussion] Array Protocol change for Python 2.6

[Tim Hochberg]

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