On Sun, May 29, 2011 at 11:48 PM, Lenard Lindstrom
<len-l@xxxxxxxxx> wrote:
Hi,
The last few days I've been adding an array struct interface to PixelArray. This lets a PixelArray object be converted to another type that recognizes the interface, (e.g. a NumPy array, though why one would do that is beyond me). However, in doing so I uncovered a bug slicing (A unit test exposing the bug was committed as rev. 3109). The bug was fixed in rev. 3126.
In fixing the bug and adding an array interface I found it easier to rework the PixelArray internals to use shape and strides rather than start, stop, and step. While doing so I discovered several unique PixelArray behaviors. <1> There was no way to get a (1, h) or (w, 1) PixelArray. The array would be one dimensional instead. <2> A sequence (e.g. list) of integers can be assigned to a PixelArray as a sequence of colors. However, a length 3 sequence is treated as a single (r, g, b) color. What about the (unlikely) case of assigning a sequence to a (3, h) PixelArray? <3> if a sequence is not length w, but rather length h, it is copied to each column rather than row. What is to be done with a square surface?
Behavior <1> was changed in rev. 3126. A one dimensional PixelArray is only created for an integer index (e.g. pixel_array[2, :]). Behavior <2> might be handled by regarding a pygame.Color or tuple object as a single (r, g, b[, a]) color, while any other sequence is handled as a sequence of colors. I don't know what to do with behavior <3>. It has a specific test in the PixelArray unit tests.
So I see two options. First, I can revert PixelArray back to before I reworked it, since some of the modifications are not backward compatible. Then I would add my reworked version as a new array type. Second, I can go ahead and make the changes I see as necessary, even when they break backward compatibility. Specifically for behavior <3>, I would remove it. Instead I would provide a transpose method that flips the PixelArray rows and columns. No special treatment would be made for (w, 1) and (1, h) arrays since special treatment could hide mismatched surface bugs.
I am open to suggestions.
Lenard Lindstrom