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

Not everyone wanting to do something with a Py_buffer constructs a
memoryview, so it sounds sensible to give Py_buffer users as much power
as memoryview users.

Otherwise, let's kill Py_buffer as an independent struct, keep
memoryview as the only building block of the buffer API... something
which I totally agree with (but apparently others don't).

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

And I think I've made my point that it's a broken design principle,
leading to two types instead of one.

May I remind you that:
  Simple is better than complex.
  Complex is better than complicated.
?