Nick Coghlan <ncoghlan <at> gmail.com> writes: > > I don't see anything wrong with the PEP 3118 protocol.
Apart from the fact that: - it uses something (Py_buffer) which is not a PyObject and has totally different allocation/lifetime semantics (which makes it non-trivial to adapt to for anyone used to the rest of the C API) - it has unsolved issues like allocation of the underlying shape and strides members - it doesn't specify how to obtain e.g. a sub-buffer, or even duplicate an existing one (which seem to be rather fundamental actions to me) ... I agree there's nothing wrong with it! > That Py_buffer describes the *whole* data store, but a memoryview slice > may only be exposing part of it - so while the info in the Py_buffer is > accurate for the underlying object, it is *not* accurate for the > memoryview itself. And the problem here is that Py_buffer is/was (*) not flexible enough to allow easy modification in order to take a sub-buffer without some annoying problems. (*) my patch solves the one-dimensional case. People interested in the multi-dimensional case will have to do their homework themselves! 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
