Hi Maciek, On Mon, Feb 11, 2008 at 05:00:29PM +0100, Maciek Fijalkowski wrote:

I feel a bit clueless about buffer protocol. Current implemntation in pypy is purely app-level, which means it's slow, but more importantly, one cannot get raw, C-level address of it. I've tried approaching the problem, but it seems that there are several serious issues.

* what's the future of buffer protocol? * do people use that? ctypes tests are relying on it. anybody knows ctypes module implementation that relies on it? * testing suite sucks. we've got two tests, cpython is not any better in this regard.

where to proceed?

The future of the buffer protocol, in Python 3000, is to be a bit cleaned up and then made considerably more complicated and powerful (being in this respect similar to most changes in Python 3000). The PEP is here: http://svn.python.org/projects/peps/trunk/pep-3118.txt I think we could still use this as a basis for thought. An interesting thing is that for any object supporting the buffer protocol, a Python object of the new type "memoryview" can be built. This is similar to the existing "buffer" Python type but cleaner in the sense that it is equivalent to the internal data structures -- in fact I'm not sure why Python 3000 needs both an internal data structure and the memoryview object type. What we could do is thus add an interp-level class MemoryView which is a subclass of Wrappable with an API to allow interp-level accesses. To get such a MemoryView from any Python object we'd use a space method, space.memoryview_w(). A trivial extension to Python would be to have a special method name associated to this, like '__memoryview__()', allowing any Python type (built-in or user-defined) to return a MemoryView for itself. The API of MemoryView could be loosely based on (but much much simpler than) the one in the PEP. A bientot, Armin.

Hi Maciek, On Mon, Feb 11, 2008 at 05:00:29PM +0100, Maciek Fijalkowski wrote:

I feel a bit clueless about buffer protocol. Current implemntation in pypy is purely app-level, which means it's slow, but more importantly, one cannot get raw, C-level address of it. I've tried approaching the problem, but it seems that there are several serious issues.

* what's the future of buffer protocol? * do people use that? ctypes tests are relying on it. anybody knows ctypes module implementation that relies on it? * testing suite sucks. we've got two tests, cpython is not any better in this regard.

where to proceed?

The future of the buffer protocol, in Python 3000, is to be a bit cleaned up and then made considerably more complicated and powerful (being in this respect similar to most changes in Python 3000). The PEP is here: http://svn.python.org/projects/peps/trunk/pep-3118.txt I think we could still use this as a basis for thought. An interesting thing is that for any object supporting the buffer protocol, a Python object of the new type "memoryview" can be built. This is similar to the existing "buffer" Python type but cleaner in the sense that it is equivalent to the internal data structures -- in fact I'm not sure why Python 3000 needs both an internal data structure and the memoryview object type. What we could do is thus add an interp-level class MemoryView which is a subclass of Wrappable with an API to allow interp-level accesses. To get such a MemoryView from any Python object we'd use a space method, space.memoryview_w(). A trivial extension to Python would be to have a special method name associated to this, like '__memoryview__()', allowing any Python type (built-in or user-defined) to return a MemoryView for itself. The API of MemoryView could be loosely based on (but much much simpler than) the one in the PEP. A bientot, Armin.