Modify it to print a warning to stderr and then go ahead for 1.8.1, then throw an error in 1.9?
-FM On 6/10/08, René Dudfield <[EMAIL PROTECTED]> wrote: > 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 >>>> > >>>> >>> >> >
