[Numpy-discussion] Buffer Interface for Python 3.0

Travis Oliphant oliphant@ee.byu....
Tue Feb 27 17:29:51 CST 2007

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




More information about the Numpy-discussion mailing list