That was the point, yes. Silently failing is a Bad Idea. -FM
On 6/10/08, Brian Fisher <[EMAIL PROTECTED]> wrote: > I assume you are saying surface.unlock should throw an exception as opposed > to do nothing in the cases where it's not valid? (if so, I agree) > > Or was there some other condition you were thinking of as well? > > On Tue, Jun 10, 2008 at 3:23 PM, Charlie Nolan <[EMAIL PROTECTED]> > wrote: > >> Errors should never pass silently. >> Unless explicitly silenced. >> >> -FM >> >> On 6/10/08, Marcus von Appen <[EMAIL PROTECTED]> wrote: >> > Hi, >> > >> > regarding Jake's unlock() report I changed the locking behaviour to be >> > more strict about who can unlock a locked surface. >> > >> > While it was possible to completely unlock a surface at any time from >> > anywhere, it is now strongly tied to the object, which caused the lock. >> > >> > While it was possible to do stuff like >> > >> > subsurface = surface.subsurface (...) >> > subsurface.lock () >> > surface.unlock () >> > # surface is unlocked again although subsurface is locked >> > ... >> > sfarray = pygame.surfarray.pixels3d(surface) >> > surface.unlock () >> > # Monsters live here >> > ... >> > >> > you now have to explicitly release the lock using the object that caused >> > it: >> > >> > subsurface = surface.subsurface (...) >> > subsurface.unlock () >> > surface.unlock () # No effect >> > subsurface.unlock () # Now the lock is released. >> > # surface is unlocked again >> > ... >> > sfarray = pygame.surfarray.pixels3d(surface) >> > surface.unlock () # Nothing happens >> > del sfarray # Surface will be unlocked >> > # Rainbowland's coming! >> > ... >> > >> > The surface.get_locked() method was adjusted accordingly and works as >> > supposed now. Additionally the surface got a new get_locks() method, >> > which returns a tuple with the object holding a lock. Though this is not >> > always exact or very helpful, it can give you a quick overview about the >> > reason for a dangling lock (numpy surfarrays for example are not listed, >> > but a surface buffer instead as that one caused the lock). >> > >> > As this is tightly bound to reference counts, weakref pointers and other >> > big sources for errors, I beg anyone to test it extensively with your >> > code. >> > >> > Attached you'll find the patch, which hopefully brings love, joy, >> > happiness and less errors to pygame. >> > >> > Regards >> > Marcus >> > >> >
