Also note that we *need* to retain compatibility with existing code - at least for pygame 1.8.1. We shouldn't break existing code.
On Wed, Jun 11, 2008 at 8:45 AM, Charlie Nolan <[EMAIL PROTECTED]> wrote: > 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 >>> > >>> >> >
