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