[Numpy-discussion] Array Protocol change for Python 2.6
David M. Cooke
cookedm at physics.mcmaster.ca
Fri Jun 9 17:04:09 EDT 2006
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
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca
More information about the NumPy-Discussion