[Python-Dev] Allocation of shape and strides fields in Py_buffer
solipsis at pitrou.net
Wed Dec 10 13:58:20 CET 2008
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
- 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!
More information about the Python-Dev