[Numpy-discussion] Array Protocol change for Python 2.6
tim.hochberg at cox.net
Fri Jun 9 16:08:32 CDT 2006
Travis Oliphant wrote:
>Tim Hochberg wrote:
>>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?
>This is an implementation detail. I'm still trying to gather some kind
>of consensus on what to actually do here.
There were three things mixed together in my post:
1. The current implementation of __array_struct__ looks buggy. Should I
go ahead and file a bug report so that this behaviour doesn't get
blindly copied over from __array_struct__ to whatever the final dohickey
is called or is that going to be totally rewritten in any case.
2. Whether __array_struct__ or __array_interface__ or whatever it gets
called returns something that's kind of like a view (has it's own copies
of shape and strides mainly) versus an alias for the original array
(somehow tries to track the original arrays shape and strides) is a
semantic difference, not an implementation details. I suspect that no
one really cares that much about this and we'll end up doing what's
easiest to get right; I'm pretty certain that is view semantics. It may
be helpful to pronounce on that now, since it's possible the semantics
might influence the name chosen, but I don't think it's critical.
3. The implementation details I provided were, uh, implentation details.
> There is no such
>__array_interface__ attribute at this point.
>Numpy-discussion mailing list
>Numpy-discussion at lists.sourceforge.net
More information about the Numpy-discussion