![](https://secure.gravatar.com/avatar/4d021a1d1319f36ad861ebef0eb5ba44.jpg?s=120&d=mm&r=g)
I took the opportunity to go to PyCon this year and met several people there. I had a really good time although I would have liked to stay longer. If you want to see the slides for my talk they are here: http://us.pycon.org/common/talkdata/PyCon2007/045/PythonTalk.pdf It was a good opportunity to integrate better with the Python developers and keep our voices heard. I think in the long term this is going to be important. We are working actively to get something like the array interface into a re-vamped buffer interface for Python 3.0. There are some issues that arise in this process that need addressing so if you have any understanding of the array interface (or want to) please dive in and contribute. Hopefully in this process we will get tighter integration with the struct module, the array module, and ctypes as well. Most of the changes are written for back-port to Python 2.6 as well. Besides how to integrate the buffer interface with discontiguous arrays, the only other issue is how to manage the memory needed to return the shape information and the format information through the buffer interface. I think using Python CObject's (like we do for __array_struct__) is a good idea and allows flexible and simple memory management as well as fast access to direct C-like information about the array. Other solutions, however, may be better. If you have any ideas, it would be good to hear them. I would also like to get feedback on the proposed additions to the string-syntax that the struct module uses for describing data formats. In particular, I'm interested in ideas about what kind of C-API functions for processing such strings might be useful. These are some ideas that I have: 1) A function that produces a ctypes type from a string-struct description. 2) A function that produces a string-struct description from a ctypes type. 3) A function that extracts the string corresponding to a named sub-element. -Travis