ah, I mean we need to make a surfarray module with the PixelArray module - so that the surfarray keeps backwards compatibility.
So the plan is to make a python module which uses PixelArray to make a surfarray compatible module. On 8/28/07, Brian Fisher <[EMAIL PROTECTED]> wrote: > I'm not sure what you are saying here - do you just mean that the > surfarray module code will stay untouched? do you mean that surfarray > will use PixelArray for something so PixelArray needs to do that work? > or do you mean that PixelArray should implement some surfarray > functions so that it could be used as a drop-in replacement (i.e. > replace in .py files "surfarray" with "PixelArray" should work)? > > in other words how does that relate to some PixelXXX class? > > On 8/27/07, René Dudfield <[EMAIL PROTECTED]> wrote: > > One thing to note is that we need to support the surfarray interface - > > for backwards compatibility. > > > > > > On 8/28/07, Brian Fisher <[EMAIL PROTECTED]> wrote: > > > 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 <[EMAIL PROTECTED]> 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 > > > > <[EMAIL PROTECTED]> > > > > > > > > > > > > > >
