[Python-Dev] An updated extended buffer PEP

Travis Oliphant oliphant.travis at ieee.org
Wed Mar 28 01:59:43 CEST 2007

Lisandro Dalcin wrote:
> On 3/26/07, Travis Oliphant <oliphant.travis at ieee.org> wrote:
>> Here is my updated PEP which incorporates several parts of the
>> discussions we have been having.
> Travis, it looks really good, below my comments
I hope you don't mind me replying to python-dev.

> 1- Is it hard to EXTEND PyBufferProcs in order to be able to use all
> this machinery in Py 2.X series, not having to wait until Py3k?

No, I don't think it will be hard.  I just wanted to focus on Py3k since 
it is going to happen before Python 2.6 and I wanted it discussed in 
that world.
> 2- Its not clear for me if this PEP will enable object types defined
> in the Python side to export buffer info. This is a feature I really
> like in numpy, and simplifies my life a lot when I need to export
> memory for C/C++ object wrapped with the help of tools like SWIG.
This PEP does not address that.  You will have to rely on the objects 
themselves for any such information.
> 3- Why not to  constraint the returned 'view' object to be of a
> specific type defined in the C side (and perhaps available in the
> Python side)? This 'view' object could maintain a reference to the
> base object containing the data, could call releasebuffer using the
> base object when the view object is decref'ed, and can have a flag
> field for think like OWN_MEMORY, OWN_SHAPE, etc in order to properly
> manage memory deallocation. Does all this make sense?

Yes, that was my original thinking and we are kind of coming back to it 
after several iterations.   Perhaps, though we can stick with an 
object-less buffer interface but have this "view object" as an expanded 
buffer object.


More information about the Python-Dev mailing list