Maybe tack on a array at the end. PixelManipulaterArray
On 8/28/07, James Hancock <[EMAIL PROTECTED]> wrote: > > PixelManipulater??? I don't know, it seems like it could fit. You have > direct access to the pixels and manipulate them. > > On 8/28/07, Marcus von Appen <[EMAIL PROTECTED]> wrote: > > > > On, Tue Aug 28, 2007, Brian Fisher 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 > > > > Yes, that's something I fully agree to (and strongly promote Greg's > > "PixelArrayView", which fits well in my opinion). > > > > > 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. > > > > Let me get that right - on the one hand easy usage, on the other easy > > pits to jump into. Although explicit locking might let us support the > > with statement (which does not seem to fit for the PixelArray and > > automatic surface locking), it burdens the user with a lot of > > problems. He has to take care of locking in the one case while the > > surfarray module would have to take care of it automatically (due to > > backwards compatibility). That does not look straightforward to me. > > > > He also'd have to take care of a bunch of other issues such as explicit > > deletion with a guaranteed ref count of 0 _and_ unlocking - otherwise > > exceptions or other unwanted side effects might be raised. > > > > Thus I am strongly against that. Automatic locking - although it breaks > > with the with statement (which is badly designed for such a purpose in > > my opinion) - reduces the sources of errors for the developers here. > > > > > 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 > > > > Only, if it would destroy the object once the with scope is left. The > > PEP did not say that much about the object's lifetime (maybe I overread > > that), but as your example demonstrated, nothing will be cleaned up > > afterwards. > > > > Regards > > Marcus > > > > >
