Fredrik Lundh wrote:
Terry Reedy wrote:
I believe that at present PyGame can only work with external images that it is programmed to know how to import. My guess is that if image source program X (such as PIL) described its data layout in a way that NumPy could read and act on, the import/copy step could be eliminated.
I wish you all stopped using PIL as an example in this discussion; for PIL 2, I'm moving towards an entirely opaque data model, with a "data view"-style client API.
That's an un-reasonable request. The point of the buffer protocol allows people to represent their data in whatever way they like internally but still share it in a standard way. The extended buffer protocol allows sharing of the shape of the data and its format in a standard way as well. We just want to be able to convert the data in PIL objects to other Python objects without having to write special "converter" functions. It's not important how PIL or PIL 2 stores the data as long as it participates in the buffer protocol. Of course if the memory layout were compatible with the model of NumPy, then data-copies would not be required, but that is really secondary. -Travis