[Python-Dev] Extended Buffer Interface/Protocol
oliphant.travis at ieee.org
Mon Mar 26 18:49:31 CEST 2007
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
> 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.
More information about the Python-Dev