[Python-Dev] An updated extended buffer PEP

[Travis E. Oliphant]

Greg Ewing wrote:
> Here's another idea, to allow multiple views of the same
> buffer with different shape/stride info to coexist, but
> without extra provider objects or refcount weirdness.
> Also it avoids using calls with a brazillion arguments.
> 
>    struct bufferinfo {
>      void **buf;
>      Py_ssize_t *len;
>      int *writeable;
>      char **format;
>      int *ndims;
>      Py_ssize_t **shape;
>      Py_ssize_t **strides;
>      int **isptr;
>    };
> 
>    int (*getbuffer)(PyObject *obj, struct bufferinfo *info);
> 
>    int (*releasebuffer)(PyObject *obj, struct bufferinfo *info);
>

This is not much different from my original "view" object.  Stick a 
PyObject_HEAD at the start of this bufferinfo and you have it.

Memory management was the big reason I wanted to do something like this.

I don't see why a PyObject_HEAD would make anything significantly 
slower.  Then we could use Python's memory management very easily to 
create and destroy these things.  This bufferinfo object would become 
the "provider" I was talking about.

> If the object has constant shape/stride info, it just fills
> in the info struct with pointers to its own memory, and does
> nothing when releasebuffer is called (other than unlocking
> its buffer).
> 
> If its shape/stride info can change, it mallocs memory for
> them and copies them into the info struct. When releasebuffer
> is called, it frees this memory.

> 
> It is the responsibility of the consumer to ensure that the
> base object remains alive until releasebuffer has been called
> on the info struct (to avoid leaking any memory that has
> been malloced for shapes/strides).

This is a reasonable design choice.  I actually prefer to place all the 
buffer information in a single object rather than the multiple argument 
design because it scales better and is easier to explain and understand.

-Travis