Nick Coghlan <ncogh...@gmail.com> added the comment: Trying another way of getting the point across... if Py_buffer wasn't defined in PEP 3118, there would have to be some *other* API there whereby the memoryview implementation could ask an object for a description of the data layout of the object's buffer.
It is Py_buffer which allows the implementation of memoryview to even be contemplated. The one point where the PEP is silent (and I think this might be what you've been attempting to get at) is as to whether or not it is OK for a client to *modify* the contents of the Py_buffer structure before passing it back in to PyBuffer_Release. And to that I would say that a robust type implementation shouldn't be assuming *anything* about the contents of the Py_buffer passed to PyBuffer_Release. If it needs to do more than decrement a reference count when the buffer is released (e.g. releasing memory allocated for shapes and strides information), then it should be doing its own internal bookkeeping based on the address of the Py_buffer object originally passed to PyObject_GetBuffer. _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4580> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
