[Python-3000] Revised PEP for buffer protocol

Nick Coghlan ncoghlan at gmail.com
Wed Mar 21 10:47:19 CET 2007


Josiah Carlson wrote:
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Josiah Carlson wrote:
>>> "Travis E. Oliphant" <oliphant.travis at ieee.org> wrote:
>>>>     The buffer interface should allow discontiguous memory areas to
>>>>     share standard striding information.  However, consumers that do
>>>>     not want to deal with strided memory should also be able to
>>>>     request a contiguous segment easily.
>>> I don't believe this is necessary.  While the point of the buffer
>>> interface is to offer direct access to memory regions of an object or
>>> structure, being able to ask "can I get a contiguous segment" isn't
>>> really reasonable. The response is either going to be "yes, that's how I
>>> represent it anyways" or "no, that's not how I represent the data".  But
>>> this bit of meta information is easily acquired by *getting* the buffer
>>> and checking the stride.
>> I think the point is for there to be something in the standard library 
>> or Python core that makes it easy for a consumer to *copy* the data to a 
>> contiguous memory segment in the event the consumer can't directly 
>> handle non-contiguous data (e.g. a C API function that takes the source 
>> object, a pointer to the destination memory block, and an optional slice 
>> object defining a subsection of the memory block to be retrieved)
> 
> But that still isn't a use-case for the "I want a contiguous view".  The
> consumer needs to construct a memory region, copy the non-contiguous
> data, then pass it on somewhere else.  The object offering the original
> view shouldn't need to offer anything special to make it happen.

It's a use case that any C API updates associated with this PEP need to 
handle though. It's along the lines of a type supporting 3 different 
abstract C API functions just by providing a tp_index slot.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org


More information about the Python-3000 mailing list