RetroSearch Browse

Wed Dec 10 17:37:22 CET 2008 · https://mail.python.org/pipermail/python-dev/2008-December/084208.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2008-December/084208.html below:

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