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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
