[Python-Dev] A simplified extended buffer PEP

[Jim Jewett]

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