[Python-3000] Using memoryviews

Benjamin Peterson musiccomposition at gmail.com
Sat Nov 22 00:52:20 CET 2008


On Fri, Nov 21, 2008 at 5:34 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Benjamin Peterson wrote:
>> On Fri, Nov 21, 2008 at 1:41 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>>> In the past, we've always tried to provide abstract access methods to
>>> C struct internals of Python objects and I wonder whether this was
>>> deliberately not done for Py_buffer structs or simply not considered.
>>>
>>> I don't think it's a good idea to use my_Py_buffer->buf in a C
>>> extension and would rather like to write:
>>>
>>> Py_Buffer_AS_BUFFER(my_Py_buffer)
>>> Py_Buffer_GET_SIZE(my_Py_buffer)
>>> Py_Buffer_GET_ITEM_SIZE(my_Py_buffer)
>>> etc.
>>
>> I think that's a good idea, too, and we should get something like that
>> in for 3.1. I rather feel like the new buffer API slipped in without
>> any real review.
>
> The review that was done was actually quite extensive - see PEP 3118.
> However:
> 1. There's a reason 3118 is still at accepted rather than final - the
> major foundations (and the all-important underlying protocol) are in
> place, but there are finishing touches still needed.
> 2. The review of the PEP focused on the power and capabilities of the
> underlying protocol and less on the aesthetics of the C API.

I'm not talking necessarily about the PEP and API. I find the
implementation confusing and contradictory in some places.

>
> The PEP was fairly explicit that the fields in the Py_buffer struct were
> public and accessed directly via C syntax though, as are the current
> docs (http://docs.python.org/dev/3.0/c-api/buffer.html).

Well, I wrote those based on the PEP. :)



-- 
Cheers,
Benjamin Peterson
"There's nothing quite as beautiful as an oboe... except a chicken
stuck in a vacuum cleaner."


More information about the Python-3000 mailing list