Sasha wrote: >On 6/9/06, Travis Oliphant <[EMAIL PROTECTED]> 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 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
