[Python-Dev] Assertion in _PyManagedBuffer_FromObject() (original) (raw)

Stefan Krah stefan at bytereef.org
Fri Mar 2 14:33:39 CET 2012

Stefan Behnel <stefan_ml at behnel.de> wrote:

> http://docs.python.org/dev/c-api/buffer.html#Pybuffer > http://docs.python.org/dev/c-api/typeobj.html#buffer-object-structures > > Since the Pybuffer.obj filed was undocumented in 3.2, I think we're within > out rights to restrict the field to the exporter.

Careful. There are tons of code out there that use the buffer interface, and the "obj" field has been the way to handle the buffer release ever since the interface actually worked (somewhere around the release of Py3.0, IIRC). Personally, I never read the documentation above (which was written way after the design and implementation of the buffer interface).

The documentation has been largely re-written for 3.3.

looked at the (outdated) PEP, and then switched to reading the code once it started to divert substantially from the PEP. I'm sure there are many users out there who have never seen the second link above, and still some who aren't aware that the "exporting object" in the first link is required to be identical with the one that "getbuffer()" was called on. Just think of an object that acts as a fa??ade to different buffers.

That's exactly what the ndarray test object from Modules/_testbuffer.c can do. You can push new buffers onto a linked list and present different ones to each consumer.

[Note that IMO that's a questionable design, but it's a test object.]

The recommended way of keeping track of resources is to use Py_buffer.internal. I think that part is also appropriately mentioned in the original PEP, though I can perfectly understand if someone misses it due to the huge amount of information that needs to be absorbed.

it's still not all that unlikely that it breaks user code (assuming that it currently works). The decision to enforce this restriction should not be taken lightly.

As I said, user code using the (also undocumented) Py_buffer.smalltable will also be broken.

Stefan Krah

More information about the Python-Dev mailing list