[Numpy-discussion] Array Protocol change for Python 2.6

[Tim Hochberg]

Sasha wrote:

>On 6/9/06, Tim Hochberg <tim.hochberg at cox.net> wrote:
>  
>
>>Sasha wrote:
>>...
>>    
>>
>>>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 my view, conceptually, __array_interface__ creates a adaptor to the
>array-like object.  What are the advantages of it being an attribute?
>It is never settable, so the most common advantage of packing get/set
>methods in a single attribute can be rulled out.  Saving typing of
>'()' cannot be taken seriousely when the name contains a pair of
>double underscores :-).
>
>There was a similar issue discussed on the python-3000 mailing list
>with respect to __hash__ method
><http://mail.python.org/pipermail/python-3000/2006-April/000362.html>.
>  
>
Isn't __array_interface__ always O(1)? By the criteria in that thread, 
that would make is good candidate for being an attribute.

[Stare at __array_interface__ spec...think..stare...]

OK, I think I'm coming around to making it a function. Presumably, in:

 >>> a = arange(6)
 >>> ai1 = a.__array_interface__()
 >>> a.shape = [3, 2]
 >>> ai2 = a.__array_interface__()

ai1 and ai2 will be different objects with different objects, pointing 
to structs with different shape and stride attributes. So, in that sense 
it's not conceptually constant and should be a function.

What happens if I then delete or resize a? Hmmm. It looks like that's 
probably OK since CObject grabs a reference to a.

FWIW, at this point, I marginally prefer array_struct to array_interface.

>  
>
>>....
>>    
>>
>>>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__?
>>
>>    
>>
>
>My metaclass idea is very similar to your unpack_interface suggestion.
> A metaclass can autonatically add
>
>def __array_tuple__(self):
>    return unpack_interface(self.__array_interface__())
>
>
>or
>
>def __array_interface__(self):
>    return pack_interface(self.__array_tuple__())
>
>to a class that only implements only one of the two required methods.
>  
>
It seems like 99% of the people will never care about this at the Python 
level, so adding an extra attribute is mostly clutter. For those few who 
do care a function seems preferable. To be honest, I don't actually see 
a need for anything other than the basic __array_struct__.


>>A single attribute seems pretty appealing to me, I'm don't see much use
>>for anything else.
>>    
>>
>
>I don't mind just having __array_struct__ that must return a CObject.
>My main objection was against a method/attribute that may return
>either CObject or something else.  That felt like shifting the burden
>from package writer to the package user.
>  
>
I concur.


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