On the one hand, I feel we should keep __array_struct__ behaving exactly as it is now. There's already lots of code that uses it, and it's tremendously useful despite (because of?) it's simplicity. For these of use cases, the __array_descr__ information has already proven unnecessary. I must say that I, and probably others, thought that __array_struct__ would be future-proof. Although the magnitude of the proposed change to add this information to the C-struct PyArrayInterface is minor, it still breaks code in the wild.
On the other hand, I'm only beginning to grasp the power of the __array_descr__ information. So perhaps bumping the PyArrayInterface.version to 3 (2 is the current, and as far as I can tell, original version) and going forward would be justified. Perhaps there's a way towards backwards-compatibility -- the various array consumers could presumably support _reading_ both v2 and version 3 nearly forever, but could spit out warnings when reading v2. It seems v3 would be a simple superset of v2, so implementation of this wouldn't be hard. The challenge will be when a implementor returns a v3 __array_struct__ to something that reads only v2. For this reason, maybe it's better to break backwards compatibility now before even more code is written to read v2. Is it clear what would need to be done to provide a C-struct giving the _array_descr_ information? What's the problem with keeping __array_descr__ access available only at the Python level? Your original email suggested limiting the number of attributes, which I agree with, but I don't think we need to go to the logical extreme. Does simply keeping __array_descr__ as part of the Python array interface avoid these issues? At what cost? Cheers! Andrew Travis Oliphant wrote: >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 > > > >_______________________________________________ >Numpy-discussion mailing list >Numpy-discussion@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
