[Python-Dev] A simplified extended buffer PEP (original) (raw)

Jim Jewett jimjjewett at gmail.com
Thu Mar 29 18:02:27 CEST 2007

Greg Ewing wrote:

Carl Banks wrote:

> /* don't define releasebuffer or lockbuffer */ > /* only objects that manage buffers themselves would define these */

That's an advantage, but it's a pretty small one ... the releaser field makes the protocol asymmetrical and thus harder to reason about.

Instead of "releaser", how about an "owner" field, that points to a PyObject? PyObject_GetBuffer will create a new reference to owner, and unlock/release is just a DECREF on that same object. (Or does redirecting the DECREF target like this look too magical?)

If a buffer exporter want to keep things simple, it can just set "owner" to self.

If it has fancier needs (such as mutating the buffer without mutating the view), then it can create a manager to do whatever it wants, and set that as the owner.

Note that the PyBufferProcs structure isn't needed any more -- from a consumer/requestor's perspective, the unlock/release is just DECREFing the owner.

Looking at

http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/doc/pep_buffer.txt

(Other than utility functions like PyObject_SizeFromFormat,) I think the entire protocol can then collapse to the bufferinfo struct and either

// might set an error and return NULL
struct bufferinfo *PyObject_GetBuffer(PyObject *obj, int flags)

or

// Replace the *view elements with the actual buffers metadata
// (return = 0) ==> success
// (return > 0) ==> modified (perhaps rejecting the RO argument)?
// (return < 0) ==> failure
int PyObject_GetBuffer(PyObject *obj, struct bufferinfo *view)

-jJ

More information about the Python-Dev mailing list