[Python-Dev] Assertion in _PyManagedBuffer_FromObject()

[Stefan Krah]

Stefan Behnel <stefan_ml at behnel.de> wrote:
> > http://docs.python.org/dev/c-api/buffer.html#Py_buffer
> > http://docs.python.org/dev/c-api/typeobj.html#buffer-object-structures
> > 
> > Since the Py_buffer.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