Re: [pygame] PixelArray question

["Brian Fisher" <brian@xxxxxxxxxxxxxxxxxxx>]

I've been thinking about all this PixelArray discussion a lot, and
I've come to think the following 3 things:
1. PixelArray would be better with another name, to make it clear that
it isn't actually an array - it just provides array access to an
existing surface's content, and such that the name makes it more
obvious why [] access would work as it does
2. Explicit locking is better than having the PixelXXX object do
automatic surface locking over it's lifetime - I think this because
the automatic locking would be arcane and non-obvious, basically a
side effect. I think that arcane behavior would be even worse cause
locking won't effect SW surfaces, so people won't be getting feedback
on whether the auto-locking is doing anything/working right. So in
those very rare cases where you might need it (HW surfaces) you aren't
likely to know it's even doing it, or to know what the gotchas that
might break it are.
3. The with statement seems to be a neat way to manage locking the
surface when you need it, because the code will be the most readable
because it would actually tie the lock behavior to a scoping block -
making all the pixel array access stuff that should be tied together
actually look together


On 8/22/07, Lenard Lindstrom <len-l@xxxxxxxxx> wrote:
> I may have missed something, but why is a separate PixelArray class
> necessary. Couldn't the array methods and buffer interface be added to
> Surface?
>
> --
> Lenard Lindstrom
> <len-l@xxxxxxxxx>
>
>