[Python-Dev] Allocation of shape and strides fields in Py_buffer (original) (raw)
Antoine Pitrou solipsis at pitrou.net
Wed Dec 10 13:58:20 CET 2008
- Previous message: [Python-Dev] Allocation of shape and strides fields in Py_buffer
- Next message: [Python-Dev] Allocation of shape and strides fields in Py_buffer
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Nick Coghlan <ncoghlan 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 Pybuffer describes the whole data store, but a memoryview slice may only be exposing part of it - so while the info in the Pybuffer 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.
- Previous message: [Python-Dev] Allocation of shape and strides fields in Py_buffer
- Next message: [Python-Dev] Allocation of shape and strides fields in Py_buffer
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]