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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com