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. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
