[Python-Dev] An updated extended buffer PEP (original) (raw)

Travis E. Oliphant oliphant.travis at ieee.org
Tue Mar 27 21:30:51 CEST 2007

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; Pyssizet *len; int *writeable; char **format; int *ndims; Pyssizet **shape; Pyssizet **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

More information about the Python-Dev mailing list