On Sun, May 29, 2011 at 11:48 PM, Lenard Lindstrom <[email protected]> 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 > Hi, I'm easy with anything you choose. Especially since that module is marked as experimental and has very few users. I'm not sure if adding an extra array type would be a good idea? cu.
