[Numpy-discussion] Array Protocol change for Python 2.6

[Travis Oliphant]

Tim Hochberg wrote:

> 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.
>>
Interesting rule.    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.


>>>   
>>
>> My problem with __array_struct__ returning either a tuple or a CObject
>> is that array protocol sholuld really provide both.
>
This is a convincing argument.   Yes, the array protocol should provide 
both.  Thus, we can't over-ride the usage of the same name unless that 
name produces an object through which both interfaces can be obtained.

Is that Sasha's suggestion?

>
> 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.

I do think it should be merged into the C struct.   The simplest thing 
to do is to have an additional PyObject * as part of the C struct which 
could be NULL (or unassigned).  The backward compatibility is a concern 
but when thinking about what Python 2.6 should support we should not be 
too crippled by it.

Perhaps we should just keep __array_struct__ and compress all the other 
array_interface methods into the __array_interface__ attribute which 
returns a dictionary from which the Python-side interface can be produced.

Keep in mind there are two different (but related) issues at play here. 

1) What goes in to NumPy 1.0
2) What we propose should go into Python 2.6


I think for #1 we should compress the Python-side array protocol into a 
single __array_interface__ attribute that returns a dictionary. We 
should also expand the C-struct to contain what _array_descr_ currently 
provides. 


-Travis