Antoine Pitrou <pit...@free.fr> added the comment: > > 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. ? _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4580> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
