[Numpy-discussion] Array Protocol change for Python 2.6

[David M. Cooke]

On Fri, 09 Jun 2006 12:08:51 -0600
Travis Oliphant <oliphant at ee.byu.edu> wrote:

> Tim Hochberg wrote:
> 
> > Sasha wrote:
> >
> >> On 6/8/06, David M. Cooke <cookedm at physics.mcmaster.ca> wrote:
> 
> >>>   
> >>
> >> 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.

True, didn't think about that. +1.

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

+1. I'm ok with two attributes: __array_struct__ (for C), and
__array_interface__ (as a dict for Python). For __array_descr__, I
would require everything that provides an __array_struct__ must also
provide an __array_interface__, then __array_descr__ can become a
'descr' key in __array_interface__. Requiring that would also mean
that any array-like object can be introspected from Python or C.

I think that the array_descr is complicated enough that keeping it as
a Python object is ok: you don't have to reinvent routines to make
tuple-like objects, and handle memory for strings, etc. If you're
using the array interface, you've got Python available: use it. If you
*do* want a C-level version, I'd make it simple, and concatenate the
typestr descriptions of each field together, like '>i2>f8', and forget
the names (you can grab them out of __array_interface__['descr'] if
you need them). That's simple enough to be parseable with sscanf.

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


-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca