An update for those of you who did not get the chance to come to PyCon. PyCon was very well attended this year and there were some excellent discussions and presentations. From PyCon I learned that Python 3000 is closer than I had previously thought. What this means for me, is that I am now focussing toward getting a re-vamped buffer interface into Python 3.0 This will help us interact with the Python developers more effectively. Once we have the buffer interface hammered out for Python 3.0 we can back-port the result to Python 2.6 Thus my buffer PEP is being re-vamped. Anybody who would like to comment or contribute to the design of the new buffer interface is welcome to voice their opinion. Basically, what we are going to do now is 1) Return the data-format specification in an extended struct-style string 2) Return the shape information in a tuple of lists: (shape, strides) There are two questions I'm grappling with right now: 1) Do we propose the inclusion of offsets in the shape information? NumPy does not use offsets internally but simply has a pointer to the start of the array. 2) The buffer interface needs to understand the idea of discontiguous arrays. If the shape/stride information is separate from the pointer-to-data call, then the user needs to know if that pointer-to-data is a "contiguous chunk" or just the beginning of a strided memory area (and so should not be treated as a single-segment). 3) If we support strided memory areas, then we should probably also allow some way for PIL-like objects to report their buffer sequence (I'm sure this was the origin of the multi-segment buffer protocol to begin with). Or we could just ignore that possibility. The PIL would have to copy memory in order to share it's images. Anybody with ideas is welcome to participate. What I have so far is at http://wiki.python.org/moin/ArrayInterface Thanks, -Travis