[Numpy-discussion] Array Protocol change for Python 2.6 (original) (raw)

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 arraystruct 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 arraydescr, 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 arraystruct and compress all the other arrayinterface methods into the arrayinterface 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 arrayinterface attribute that returns a dictionary. We should also expand the C-struct to contain what arraydescr currently provides.

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

More information about the NumPy-Discussion mailing list