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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com