[Python-3000] PEP Draft: Enhancing the buffer protcol

Daniel Stutzbach daniel at stutzbachenterprises.com
Wed Feb 28 03:00:12 CET 2007

I know I'm joining this discussion late in the game, so I apologize if
my look through the list archives was not sufficiently exhaustive and
this has been proposed and shot down before...

What if the locking mechanism were put into the array's memory instead
of the container's memory?  If the array-memory is a PyObject, then
the existing reference counting mechanism can be used, instead of
inventing a new one.  We can introduce a new type, PyArray, that is
pretty much opaque (bare minimum of methods).  A PyArray is just a
PyObject_HEAD (one type pointer plus the reference counter) followed
by the data that would normally be there.

When an array-like container allocates memory, it allocates a PyArray
to store the actual data in.  When a caller request a view, the
container increments the PyArray's reference counter and returns a
pointer to the PyArray.  The caller is responsible for decrementing
the reference counter when it is done with the view, so
bf_releasebuffer becomes unnecessary.

The container cannot reallocate the memory unless the reference
counter on the PyArray is exactly 1.

Basically, I'm wondering if it makes sense to move the new reference
counter into the buffered memory rather than putting it in the
container, so that there is only one reference counter implementation.

Different question: what is a container supposed to do if a view is
locking its memory and it needs to reallocate to complete some
operation?  I assume it would raise an exception, but it would be nice
to spell this out in the PEP.

Daniel Stutzbach, Ph.D.             President, Stutzbach Enterprises LLC

More information about the Python-3000 mailing list