On 20 March 2017 at 12:25, René Dudfield <renesd@xxxxxxxxx> wrote:
The stronger evidence of tests passing, and no concrete theoretical reasons presented on why it can't be compatible suggests to me that it can be done.
I don't know a lot about SDL, but the transition sounds like a big change. And my experience is that any big change inevitably makes things break. People will rely on undocumented, untested features, and things that aren't features at all but just happen to work. There are some old stories about the lengths Microsoft went to for backwards compatibility in Windows, which included checking when a certain popular game was started, and then emulating an old bug which that game happened to rely on. I don't think we're going to be doing that sort of thing.
I also don't see the advantage of having one version of pygame that can be built with two different versions of SDL. When people install it, they're getting one or the other version of SDL, not both. If they install it with SDL 1, they don't benefit from the SDL 2 support. If they install it with SDL 2, there's just as much risk of incompatibility as if they had to install a different version or different package for pygame with SDL 2. And recompiling to switch between the two is harder than simply running 'pip install pygame<2'.
This (supporting both SDLs in the same pygame release) is a separate question from making pygame API compatible when it moves to SDL 2 by default. That's an easier case to make - though I think there's also a case for letting pygame 1.x go quietly into the sunset supporting games already built for it, and making pygame2 for new games with some API breakage.
At the heart of this, there's a question about how pygame users see game development: do you work on one game in an ongoing manner, adding support for new libraries and platforms as they come up? Or do you develop and release a game with the pieces available at the time, and then move on to a new project? Commercial games appear to follow the latter description more, and contests like pyweek lend themselves to develop-and-stop, which suggests that preserving API compatibility is not all that important. But maybe lots of other games follow the latter model.
> Holding onto legacy books, apps, tutorials is only hindering the progress of a modern Python game library.
Leif, while I agree with your points about complexity and compatibility, I think that the body of experience with pygame - in the form of tutorials, books, etc. - is actually a strength, and perhaps even the reason that people are still wanting to use it when there are so many newer tools. So I think it would be good to keep the API similar enough that those materials are still applicable.