[Python-Dev] Extended Buffer Interface/Protocol

[Greg Ewing]

Carl Banks wrote:

> It's easy to see possible use cases for returning a different object.  A 
>   hypothetical future incarnation of NumPy might shift the 
> responsibility of managing buffers from NumPy array object to a hidden 
> raw buffer object.  In this scenario, the NumPy object is the exporter, 
> but the raw buffer object the provider.

But since the NumPy object has to know about the provider,
it can simply pass the release call on to it if appropriate.
I don't see how this case necessitates making the release call
on a different object.

I'm -1 on involving any other objects or returning object
references from the buffer interface, unless someone can
come up with a use case which actually *requires* this
(as opposed to it just being something which might be
"nice to have"). The buffer interface should be Blazingly
Fast(tm), and messing with PyObject*s is not the way to
get that.

> > This makes me wonder if releasebuffer should contain an argument which 
> > states whether or not to release the memory, the shape and strides 
> > information, the format information, or all of it.
>
> Here's what I think: the lock should only apply to the buffer itself, 
> and not to shape and stride data at all.  If the requestor wants to keep
> its own copies of the data, it would have to malloc its own storage for 
> it.  I expect that this would be very rare.

Seems to me the lock should apply to *everything* returned
by getbuffer. If the requestor is going to iterate over the
data, and there are multiple dimensions, surely it's going to
want to refer to the shape and stride info at regular intervals
while it's doing that. Requiring it to make its own copy
would be a burden.

--
Greg