I would disagree that it's more important that all the code that ran before runs on the new version without exception than it is to change the new version so that bad nonfunctioning or error-prone code doesn't silently fail.
The way I think of it is, What happens when the code that didn't run before fails to run with the new error checking? If what happens is the developer learns that the code is bad and it breaks and messes up locking, and it gets rewritten in a way that makes sense, than I say it's a good thing, and if that developer were me I would appreciate it very much that the behavior changed. I do admire and appreciate the devotion to backwards compatibility, I just think there are cases that are worth changing the behavior, and so far this seems like a good one to me. On Tue, Jun 10, 2008 at 6:07 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > sure. We want to try to not breaking existing code if possible. > > Note, that currently Marcus's code seems to work with the existing > surfarray using code that I've tried. I've tried the > example/arraydemo.py and one app so far. > > Here's a list of surfarray using code if someone wants to test more: > http://www.google.com/codesearch?q=import+surfarray > > cheers, > > > > On Wed, Jun 11, 2008 at 10:26 AM, Brian Fisher > <[EMAIL PROTECTED]> wrote: > > Even bad broken code? > > > > On Tue, Jun 10, 2008 at 4:09 PM, 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. > >> >
