> Why a borrowed reference rather than a new one? It could be decref'ed as > part as the proposed PyBuffer_Release procedure.
The question is a) whether a Py_Buffer remains valid even if the object goes away. That seems not to be the case, i.e. the caller of getbuffer needs to hold onto the object, anyway. b) whether it would still be correct to call releasebuffer explicitly. Of course, as getbuffer would have to fill the object into the view, releasebuffer could also DECREF the included object. Alternatively, there could be a pair of functions PyBuffer_Get and PyBuffer_Release, which would fill the object into the view itself. So I withdraw issue b; the real question remains whether it is desired that a buffer will remain alive as long as there is a view to it. That is a question for the buffer experts to answer; it may also have impacts on cyclic garbage collection (as inclusion of a view into an object will mean that the tp_traverse function must also Py_VISIT the embedded object). > Overall it sounds like a clean resolution of the problem. Unfortunately, it's also a significant change at this point. I personally won't have time to provide a patch, but I think a patch is needed before the last beta. IOW, the issue should become a release blocker. Regards, Martin _______________________________________________ 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
