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

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