[Python-Dev] Extended buffer PEP

[Carl Banks]

Only one concern:

 >     typedef int (*getbufferproc)(PyObject *obj, struct bufferinfo *view)


I'd like to see it accept a flags argument over what kind of buffer it's 
allowed to return.  I'd rather not burden the user to check all the 
entries in bufferinfo to make sure it doesn't get something unexpected.

I imagine most uses of buffer protocol would be for direct, 
one-dimensional arrays of bytes with no striding.  It's not clear 
whether read-only or read-write should be the least common denominator, 
so require at least one of these flags:

Py_BUF_READONLY
Py_PUF_READWRITE

Then allow any of these flags to allow more complex access:

Py_BUF_MULTIDIM - allows strided and multidimensional arrays
Py_BUF_INDIRECT - allows indirect buffers (implies Py_BUF_MULTIDIM)

An object is allowed to return a simpler array than requested, but not 
more complex.  If you allow indirect buffers, you might still get a 
one-dimensional array of bytes.


Other than that, I would add a note about the other things considered 
and rejected (the old prototype for getbufferproc, the delegated buffer 
object).  List whether to backport the buffer protocol to 2.6 as an open 
question.

Then submit it as a real PEP.  I believe this idea has run its course as 
PEP XXX and needs a real number.  (I was intending to start making 
patches for the Py3K library modules as soon as that happened.)

Carl Banks


Travis Oliphant wrote:
> 
> Here is my "final" draft of the extended buffer interface PEP.
> For those who have been following the discussion, I eliminated the 
> releaser object and the lock-buffer function.   I decided that there is 
> enough to explain with the new striding and sub-offsets without the 
> added confusion of releasing buffers, especially when it is not clear 
> what is to be gained by such complexity except a few saved lines of code.
> 
> The striding and sub-offsets, however, allow extension module writers to 
> write code (say video and image processing code or scientific computing 
> code or data-base processing code) that works on any object exposing the 
> buffer interface.  I think this will be of great benefit and so is worth 
> the complexity.
> 
> This will take some work to get implemented for Python 3k.  I could use 
> some help with this in order to speed up the process.  I'm working right 
> now on the extensions to the struct module until the rest is approved.
> 
> Thank you for any and all comments:
> 
> -Travis