[Python-Dev] Extended buffer PEP (original) (raw)
Travis Oliphant oliphant.travis at ieee.org
Sun Apr 8 19:17:12 CEST 2007
- Previous message: [Python-Dev] Extended buffer PEP
- Next message: [Python-Dev] Extended buffer PEP
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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: PyBUFREADONLY PyPUFREADWRITE Then allow any of these flags to allow more complex access: PyBUFMULTIDIM - allows strided and multidimensional arrays PyBUFINDIRECT - allows indirect buffers (implies PyBUFMULTIDIM) 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
- Previous message: [Python-Dev] Extended buffer PEP
- Next message: [Python-Dev] Extended buffer PEP
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]