homepage

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