[pygame] What to do with PixelArray?

[Lenard Lindstrom <len-l@xxxxxxxxx>]

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