[Python-Dev] Extended buffer PEP
Travis Oliphant
oliphant.travis at ieee.org
Sun Apr 8 19:17:12 CEST 2007
Carl Banks wrote:
> 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.
Yes, I agree. We had something like that at one point.
>
> 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.
Thanks for the suggestions.
>
> Then submit it as a real PEP. I believe this idea has run its course
> as PEP XXX and needs a real number.
How does one do that. Who assigns the number? I thought I "had"
submitted it as a real PEP.
-Travis
More information about the Python-Dev
mailing list