[Python-Dev] Assertion in _PyManagedBuffer_FromObject()

Stefan Behnel stefan_ml at behnel.de
Sat Mar 3 09:58:38 CET 2012


Nick Coghlan, 03.03.2012 00:49:
> On Sat, Mar 3, 2012 at 3:14 AM, Stefan Behnel wrote:
>> Stefan Krah, 02.03.2012 17:42:
>>> The reason why this scheme was not chosen for a chain of memoryviews
>>> was that 'exporter' (in theory) could implement a slideshow of buffers,
>>> which means that in the face of redirecting requests m might not be
>>> equal to nd.
>>
>> Right. Then it's only safe when the intermediate provider knows what the
>> underlying buffer providers do. Not unlikely in an application setting,
>> though, and it could just be an option at creation time to activate the
>> delegation for the ndarray above.
> 
> OK, my take on the discussion so far:
> 
> 1. assert() is the wrong tool for this job

Absolutely.


> 2. the current check is too strict (it should just check for obj !=
> NULL, not obj == &exporter)

I don't know. The documentation isn't very clear on the cases where obj may
be NULL. Definitely on error, ok, but otherwise, the bf_getbuffer() docs do
not explicitly say that it must not be NULL (they just mention a "standard"
case):

http://docs.python.org/dev/c-api/typeobj.html#buffer-object-structures

and the Py_buffer docs say explicitly that the field either refers to the
exporter or is NULL, without saying if this has any implications or
specific meaning:

http://docs.python.org/dev/c-api/buffer.html#Py_buffer

Personally, I don't see a NULL (or None) value being a problem - it would
just mean that the buffer does not need any release call (i.e. no cleanup),
e.g. because it was statically allocated in an extension module.
PyBuffer_Release() has the appropriate checks in place anyway. But I don't
care either way, as long as it's documented.

Stefan



More information about the Python-Dev mailing list