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

Nick Coghlan ncoghlan at gmail.com
Mon Dec 8 22:42:37 CET 2008


Antoine Pitrou wrote:
> Nick Coghlan <ncoghlan <at> gmail.com> writes:
>> Actually, I think your suggested scheme for the one-dimensional case
>> shows the way forward: ownership of the shape and strides memory belongs
>> to the object issuing the Py_buffer struct, and that object needs to
>> deal with it when the buffer is released. Defining a larger memory chunk
>> with the Py_buffer as the first item and the shape and stride info
>> tacked onto the end and returning that from PyObject_GetBuffer() means
>> that the shape/stride info will be released automatically when the view
>> is released via PyBuffer_Release().
> 
> Ok, so another question: given that this will change the Py_buffer layout a bit,
> can it go into 3.0.1 and 2.6.2?

No, you misunderstand what I meant. Py_buffer doesn't need to be changed
at all. The *issuing type* would define a new structure with the
additional fields, such as:

struct _my_Py_buffer {
  Py_buffer     view;
  SHAPE_TYPE    shape;
  STRIDES_TYPE  strides;
}

Internally, the object would use these instead of vanilla Py_buffer
objects, and set the shape and strides pointers inside the view field to
refer to the shape and strides fields.

Clients wouldn't need to know or care that the shape and stride
information had been tacked on to the end of the Py_buffer struct. When
the buffer was released via PyBuffer_Release, the object would throw
away the whole _my_Py_buffer structure (since the pointers are the same).

Alexander's suggestion of going and looking at what the numpy folks have
done in this area is probably a good idea too.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


More information about the Python-Dev mailing list