[Numpy-discussion] Array Protocol change for Python 2.6

[Tim Hochberg]

Sasha wrote:

>On 6/8/06, David M. Cooke <cookedm at physics.mcmaster.ca> wrote:
>  
>
>>...
>>+0 for name change; I'm happy with it as an attribute.
>>
>>    
>>
>My rule of thumb for choosing between an attribute and a method is
>that attribute access should not create new objects.
>
Conceptually at least, couldn't there be a single __array_interface__ 
object associated with a given array? In that sense, it doesn't really 
feel like creating a new object.

>  In addition, to
>me __array_interface__ feels like a generalization of __array__
>method, so I personally expected it to be a method the first time I
>tried to use it.
>
>  
>
>>...
>>The idea behind the array interface was to have 0 external dependencies: any
>>array-like object from any package could add the interface, without requiring
>>a 3rd-party module. That's why the C version uses a CObject. Subclasses of
>>CObject start getting into 3rd-party requirements.
>>
>>    
>>
>
>Not necessarily.  Different packages don't need to share the subclass,
>but subclassing CObject is probably a bad idea for the reasons I will
>explain below.
>
>  
>
>>How about a dict instead of a tuple? With keys matching the attributes it's
>>replacing: "shapes", "typestr", "descr", "data", "strides", "mask", and
>>"offset". The problem with a tuple from my point of view is I can never
>>remember which order things go (this is why in the standard library the
>>result of os.stat() and time.localtime() are now "tuple-like" classes with
>>attributes).
>>
>>    
>>
>My problem with __array_struct__ returning either a tuple or a CObject
>is that array protocol sholuld really provide both.  CObject is
>useless for interoperability at python level and a tuple (or dict) is
>inefficient at the C level.  Thus a good array-like object should
>really provide both __array_struct__ for use by C modules and
>__array_tuple__ (or whatever) for use by python modules.  On the other
>hand, making both required attributes/methods will put an extra burden
>on package writers.  Moreover, a pure python implementation of an
>array-like object will not be able to provide __array_struct__ at all.
> One possible solution would be an array protocol metaclass that adds
>__array_struct__ to a class with __array_tuple__ and __array_tuple__
>to a class with __array_struct__  (yet another argument to make both
>methods).
>  
>
I don't understand this. I'm don't see  how bringing in metaclass is 
going to help a pure python type provide a sensible __array_struct__. 
That seems like a hopeless task. Shouldn't pure python implementations 
just provide __array__?

A single attribute seems pretty appealing to me, I'm don't see much use 
for anything else.


>>We still need __array_descr__, as the C struct doesn't provide all the info
>>that this does.
>>
>>    
>>
>What do you have in mind?
>  
>
Is there any prospect of merging this data into the C struct? It would 
be cleaner if all of the information could be embedded into the C 
struct, but I can see how that might be a backward compatibility nightmare.

-tim

>
>_______________________________________________
>Numpy-discussion mailing list
>Numpy-discussion at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>
>  
>