> 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.