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
Attachment:
pgp1DBlcPpXyB.pgp
Description: PGP signature