[Python-Dev] Allocation of shape and strides fields in Py_buffer (original) (raw)

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

Antoine Pitrou wrote:

Nick Coghlan <ncoghlan 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 Pybuffer struct, and that object needs to deal with it when the buffer is released. Defining a larger memory chunk with the Pybuffer as the first item and the shape and stride info tacked onto the end and returning that from PyObjectGetBuffer() means that the shape/stride info will be released automatically when the view is released via PyBufferRelease(). Ok, so another question: given that this will change the Pybuffer 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