[Python-Dev] Allocation of shape and strides fields in Py_buffer (original) (raw)

Greg Ewing greg.ewing at canterbury.ac.nz
Wed Dec 10 00:55:43 CET 2008

Antoine Pitrou wrote:

Why should it need two? Why couldn't the embedded Pybuffer fullfill all the needs of the memoryview object?

Two things here:

  1. The memoryview should not be holding onto a Py_buffer in between calls to its getitem and setitem methods. It should request one from the underlying object when needed and release it again as soon as possible.

  2. The "second" Py_buffer referred to above only needs to be materialized when someone makes a GetBuffer request on the memoryview itself. It's not needed for Python getitem and setitem calls. (The implementation might choose to implement these by creating a temporary Py_buffer, but again, it would only last as long as the call.)

If the memoryview can't be a relatively thin object-oriented wrapper around a Pybuffer, then this all screams failure to me.

It shouldn't be a wrapper around a Py_buffer, it should be a wrapper around the buffer interface of the underlying object.

In all honesty, I admit I am annoyed by all the problems with the buffer API / memoryview object, many of which are caused by its utterly bizarre design

It sounds to me like whoever wrote the memoryview implementation didn't understand how the buffer interface is meant to be used. That doesn't mean there's anything wrong with the buffer interface.

I have some doubts myself about whether it needs to be as complicated as it is, but I think the basic idea is sound: that Py_buffer objects are ephemeral, to be obtained when needed and not kept for any longer than necessary.

-- Greg

More information about the Python-Dev mailing list