On Fri, 09 Jun 2006 12:08:51 -0600 Travis Oliphant <[EMAIL PROTECTED]> wrote:
> Tim Hochberg wrote: > > > Sasha wrote: > > > >> On 6/8/06, David M. Cooke <[EMAIL PROTECTED]> 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/ |[EMAIL PROTECTED] _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
