> >> 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.
> 
> malloc/free modelled semantics have *nothing* to do with Py_buffer
> being a full PyObject in its own right.

Well, the moment you're talking about having a struct of heterogeneous
fields whose address should remain identical, why not use the one
internal abstraction that is designed exactly for that, aka PyObject.
Sure you can devise an other ownership model, but what's the point?
I'm talking about avoiding NIH and an additional maintenance burden due
to avoidable cruft.

> > 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.
> 
> Such code is likely to be broken regardless of how we clarify the
> semantics,

Well, PyMemoryView_FromBuffer is used in the stdlib right now (in the IO
lib).

> I think Pauli's right, we need to make memoryview
> re-exporting significantly smarter in order to cope correctly with
> mutable objects.

Ok.

> 1. Add "PyManagedBuffer" as an even lower level wrapper around
> Py_buffer. The only thing this would support is doing GetBuffer on
> construction and ReleaseBuffer when destroyed (or when explicitly
> asked to do so), as well as access to the information in the Py_buffer
> struct.
> 
> 2. Adjust PyMemoryView to use that object to access the source object
> that implements the PEP 3118 API.

Ouch. Why not fold all that directly into memoryview? A third
abstraction for support of what is supposed to be a simple API sounds 
too much.
(see, if Py_buffer was a PyObject, we'd have only one abstraction)