Nick Coghlan <ncogh...@gmail.com> 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 - 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. _______________________________________ 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
