[Python-Dev] Allocation of shape and strides fields in Py_buffer
Travis Oliphant
oliphant.travis at ieee.org
Wed Dec 10 17:37:22 CET 2008
Antoine Pitrou wrote:
> 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)
* this is a non-issue. The Py_buffer struct is just a place-holder
for a bunch of variables. It could be a Python-object but that was seen
as unnecessary.
> - it has unsolved issues like allocation of the underlying shape and strides
> members
* this is false. It does specify how this is handled.
> - 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)
* this is not part of the PEP. Whether it's a deficiency or not is
open to interpretation.
>
> ... I agree there's nothing wrong with it!
I'm glad you agree.
>
>> 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.
>
You are confusing the intent of the memoryview with the Py_buffer struct.
-Travis
More information about the Python-Dev
mailing list