[Python-Dev] Extended Buffer Interface/Protocol

[Travis Oliphant]

Carl Banks wrote:
> We're done.  Return pointer.

Thank you for this detailed example.  I will have to parse it in more 
depth but I think I can see what you are suggesting.

> 
> First, I'm not sure why getbuffer needs to return a view object. 

The view object in your case would just be the ImageObject.  The reason 
I was thinking the function should return "something" is to provide more 
flexibility in what a view object actually is.

I've also been going back and forth between explicitly passing all this 
information around or placing it in an actual view-object.  In some 
sense, a view object is a NumPy array in my mind.  But, with the 
addition of isptr we are actually expanding the memory abstraction of 
the view object beyond an explicit NumPy array.

In the most common case, I envisioned the view object would just be the 
object itself in which case it doesn't actually have to be returned. 
While returning the view object would allow unspecified flexibilty in 
the future, it really adds nothing to the current vision.

We could add a view object separately as an abstract API on top of the 
buffer interface.

> 
> 
> Second question: what happens if a view wants to re-export the buffer? 
> Do the views of the buffer ever change?  Example, say you create a 
> transposed view of a Numpy array.  Now you want a slice of the 
> transposed array.  What does the transposed view's getbuffer export?

Basically, you could not alter the internal representation of the object 
while views which depended on those values were around.

In NumPy, a transposed array actually creates a new NumPy object that 
refers to the same data but has its own shape and strides arrays.

With the new buffer protocol, the NumPy array would not be able to alter 
it's shape/strides/or reallocate its data areas while views were being 
held by other objects.

With the shape and strides information, the format information, and the 
data buffer itself, there are actually several pieces of memory that may 
need to be protected because they may be shared with other objects. 
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.

Having such a thing as a view object would actually be nice because it 
could hold on to a particular view of data with a given set of shape and 
strides (whose memory it owns itself) and then the exporting object 
would be free to change it's shape/strides information as long as the 
data did not change.

> 
> The reason I ask is: if things like "buf" and "strides" and "shape" 
> could change when a buffer is re-exported, then it can complicate things 
> for PIL-like buffers.  (How would you account for offsets in a dimension 
> that's in a subarray?)

I'm not sure what you mean, offsets are handled by changing the starting 
location of the pointer to the buffer.

-Travis