[Python-Dev] Allocation of shape and strides fields in Py_buffer

Antoine Pitrou solipsis at pitrou.net
Wed Dec 10 00:15:58 CET 2008

Nick Coghlan <ncoghlan <at> gmail.com> writes:
> For the slicing problem in particular, memoryview is currently trying to
> get away with only one Py_buffer object when it needs TWO.

Why should it need two? Why couldn't the embedded Py_buffer fullfill all the
needs of the memoryview object? If the memoryview can't be a relatively thin
object-oriented wrapper around a Py_buffer, then this all screams failure to me.


In all honesty, I admit I am annoyed by all the problems with the buffer API /
memoryview object, many of which are caused by its utterly bizarre design (and
the fact that the design team went missing in action after imposing such a
bizarre and complex design on us), and I'm reluctant to add yet another level of
byzantine complexity in order to solve those problems. It explains I may sound a
bit angry at times :-)

If we really need to change things a lot to make them work, we should re-work
the buffer API from the ground up, make the Py_buffer struct a true PyObject
(that is, a true variable-length object so as to solve the shape and strides
allocation issue) and merge it with the current memoryview implementation. It
would make things both more simpler and more flexible.

But of course it would destroy C-level compatibility with 2.6 / 3.0.



More information about the Python-Dev mailing list