[Python-Dev] PEP 296 - The Buffer Problem

[Scott Gilbert]

--- Thomas Heller <thomas.heller@ion-tof.com> wrote:
> What if we would 'fix' the buffer interface?
> 

This gets us part of the way there, but still has shortcomings.  For one I,
and people more significant than me, would still need a type that
implemented the bytes object behavior.  Everything but efficient pickling
_could_ be done with third party extensions, but ignoring pickling (which I
don't want to do), then we'd still have several significant third parties
reinventing the same wheel.  To me at least, this feels like a battery that
should be included.


> Extend the PyBufferProcs structure by new fields:
> 
>     typedef size_t (*getlargereadbufferproc)(PyObject *, void **);
>     typedef size_t (*getlargewritebufferproc)(PyObject *, void **);
> 

How would you designate failure/exceptions?  size_t is unsigned everywhere
I can find it, so it can't return a negative number on failure.  I guess
the void** could be filled in with NULL.

>
>     typedef struct {
>             getreadbufferproc bf_getreadbuffer;
>             getwritebufferproc bf_getwritebuffer;
>             getsegcountproc bf_getsegcount;
>             getcharbufferproc bf_getcharbuffer;
>             /* new fields */
>             getlargereadbufferproc bf_getlargereadbufferproc;
>             getlargewritebufferproc bf_getlargewritebufferproc;
>     } PyBufferProcs;
> 
> 
> The new fields are present if the Py_TPFLAGS_HAVE_GETLARGEBUFFER flag
> is set in the object's type. Py_TPFLAGS_HAVE_GETLARGEBUFFER implies
> the Py_TPFLAGS_HAVE_GETCHARBUFFER flag.
> 
> These functions have the same semantics Scott describes: they must
> only be implemented by types only return addresses which are valid as
> long as the Python 'source' object is alive.
> 
> Python strings, unicode strings, mmap objects, and maybe other types
> would expose the large buffer interface, but the array type would
> *not*. We could also change the name from 'large buffer interface'
> to something more sensible, currently I don't have a better name.
> 

I've been trying to keep the proposal as unintrusive as possible while
still implementing the functionality needed.  Adding more flags/members to
PyObjects and modifying string, unicode, mmap, ... feels like a more
intrusive change to me.  I'm open to the idea, but I'm not ready to retract
the current proposal.  Then there is still the problem of needing something
like a bytes object as mentioned above.


Cheers,
    -Scott


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com