Antoine Pitrou <pit...@free.fr> added the comment: > I'm still not comfortable with a convention that relies on *clients* > of the PEP 3118 API not mucking with the internals of the Py_buffer > struct.
Which clients? Those who export the buffer, or those who consume it? > I'm *much* happier with the rule based on malloc/free semantics where > the *pointer* passed to PyObject_GetBuffer must match a single later > call to PyObject_ReleaseBuffer. Agreed that Py_buffer should have been a PyObject from the start, but the PEP chose differently. We now have backwards compatibility constraints. What do we do with PyMemoryView_FromBuffer? Also, there's probably some code out there that likes to copy Py_buffers around. > As far as the question of re-exporting the underlying view or not > goes, I agree having "memoryview(a)" potentially refer to different > underlying memory from "a" itself (because the source object has > changed since the first view was exported) is a recipe for confusion. If an object changes its buffer while it's exported somewhere, it will always result in confusion for the user, regardless of how the memoryview object is implemented. All normal uses of the buffer API assume that the buffer's memory doesn't change while it's being accessed by its consumer (what would it mean to SHA1-hash or zlib-compress a changing piece of memory?). So I don't know why the memoryview object *in particular* should care about this. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10181> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com