Nick, you know a lot about this issue and I'm probably missing many things
here. I misunderstood your concept of PyManagedBuffer, so my previous
posting might have been hard to understand.

I'd appreciate if you (or anyone in this thread) could comment if the
following would work *in theory*, even if you are against an additional
getslicedbufferproc:


As I understand, there are two major issues that complicate the code:

  1) the copying in PyMemoryView_FromBuffer()
  2) slicing


To address 1), I wanted to create new memoryview objects exclusively
from proper base objects that implement the buffer protocol. So the
plan was to create small wrapper object inside PyMemoryView_FromBuffer()
that handles enough of the buffer protocol to be usable inside the stdlib
for one-dimensional objects. The actual memoryview would then be created
by calling PyMemoryView_FromObject() on that wrapper.

[PyMemoryView_FromObject() would then obviously not call PyMemoryView_FromBuffer(),
but would create the view directly.]


To address 2), buffers would *always* have to be filled in by the original
exporting object, hence the proposal to add a getslicedbufferproc.

Then memoryview would always have a proper base object and could always call
getbuffer()/INCREF(base) and releasebuffer()/DECREF(base). I thought this would
make the code much cleaner.


> Direct: the view is directly accessing an underlying object via the PEP 3118 API
> Indirect: the view has a reference to another memoryview object that it is using
>           as a data source

Is there still a difference if only the original base object manages buffers
and they are never copied?


> This is better than requiring that every implementor of the buffer API
> worry about the slicing logic - we can do it right in memoryview and then
> implementers of producer objects don't have to worry about it.

I'm not sure, but my reasoning was that e.g. in numpy the slicing logic
is already in place. Then again, I don't know if it is a legitimate use
of buf, shapes and strides to implement slicing.

According to this mail, slicing information was supposed to be
part of the memoryview struct:

http://mail.python.org/pipermail/python-dev/2007-April/072584.html