[Python-Dev] An updated extended buffer PEP (original) (raw)

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 OWNMEMORY, OWNSHAPE, 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.

-Travis

More information about the Python-Dev mailing list