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

[Antoine Pitrou]

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.