> I'm trying to be practical. If the additional shape/strides storage is
> in Py_buffer, it can benefit anyone wanting to create a subview or doint
> to do something else with shape and strides. If the storage is in
> memoryview, it only benefits memoryview.

I'm not sure I follow that - no matter where they're stored, doing
PyObject_GetBuffer on the memoryview should use the *memoryview's*
shape/stride information rather than that of the underlying object.
That's how getting this right in memoryview can help third parties: to
get a subview of something else, take a memoryview of it, slice the
memoryview, then get the Py_buffer information from the memoryview slice.

Hence my opinion that it makes sense to have an easy API (at least at
the C level) to create a memoryview given both an original object and
start/stop/step information - not only will it be useful internally for
the implementation of proper multi-dimensional slicing support in
memoryview itself, but it will also be convenient for third parties
trying to use or support the PEP 3118 protocol.

I agree wholeheartedly with your complaints about Py_buffer and the
PyObject_GetBuffer protocol being somewhat awkward to use. However, I
don't agree that it is a significant problem. One focus for the
underlying protocol design was on being fairly minimalist while still
providing sufficient expressiveness to cover all of the use cases
identified by the number crunching crowd - as Greg pointed out on
python-dev, it's best to think of Py_buffer's role in the protocol as
merely a location to store a fairly large set of output variables
describing the internal storage of the object supplying the data buffer.

The convenience layer that you're after (the one that will make the PEP
3118 API simpler to use by supporting normal PyObject semantics and easy
creation of subviews) should actually *be* memoryview, but the
implementation isn't there yet.