I think that rewriting the extension modules in cython would be a great way to make the project accessible to new developers.
Writing extensions in C, as it is now, requires that developers have 1. Good C skills, 2. Understanding of the Python C library, 3. Knowledge of the SDL library, 4. Understanding of low-level details about the platforms it supports, and finally, 5. a good sense of how pygame works. If you can imagine those skills charted as a Venn diagram, it's not difficult to understand why it is hard to maintain pygame as is, because only a handful of people have those skills and actually care. Cython is not difficult to learn and looks like Python. It would be less of a barrier of entry for new developers to contribute. Also, let's not forget that C in general is losing mindshare, as new developers tend to learn JS, java, and Python for their classes. At that point however, Toms python_sdl2 is already doing that so, where does that leave pygame2? If cython is chosen, better to let pygame 1.9 die gracefully and move on to a better platform and not duplicate effort (by moving to python_sdl2). Good night, sweet prince, in that case. On Sun, Mar 19, 2017 at 5:02 PM Lenard Lindstrom <le...@telus.net> wrote: > Hi René and everyone else, > > I like this approach. My patches achieve the first step, using SDL2. The > next step is to introduce new SDL2 features as new modules and classes. > > I suppose the SDL2 patches can be incorporated as conditionally compiled > code. They can be added one at a time, but must all be in place to work > properly. Then any new Pygame modules will expose SDL2 features only, so > not be built for SDL1. > > As a long term goal SDL1 can be removed and SDL1 legacy modules > reimplemented on top of the SDL2 specific code. > > Is there any reason new modules should not be written in Cython? If not > then we could try to use parts of pygame_sdl2 to quickly introduce SDL2 > specific features. > > Lenard Lindstrom > > > On 17-03-18 05:02 AM, René Dudfield wrote: > > Hello, > > > > so, I've spent some more time reading source code, and investigating > > SDL2 and the options a lot. > > > > I *think* this plan below could be the best way forward for us. > > > > tldr; > > * have a single source SDL1, and SDL2 code base with a compile time > > option. (like we have single source py2 and py3). > > * move bitbucket/pygame repo to github/pygame. > > > > > > Rather than reimplementing everything, and introducing lots of > > compatibility bugs, Instead I think a gradual approach would work > > better. I'm starting to think that perhaps pygame_sdl2 by Tom, is not > > such a great way forward (for the pygame project, I think it was > > necessary and good for Ren'Py). > > > > A big breaking change is kind of silly for how little resources we > > have. Python 3 managed to pull it off... after a decade, and with > > massive resources having poured into it. And it only took off once > > they put compatibility code back in. Here's the thread where some > > discussion has been happening. > > > https://bitbucket.org/pygame/pygame/issues/174/pygame-20-the-sdl2-edition > > > > > > What we do have is some patches to get the current code base working > > with SDL2. > > https://bitbucket.org/llindstrom/pygame-1.10-patch > > > > I think it should be possible with some work to improve an SDL2 > > compatibility layer, so that pygame code base can work with either (as > > a compile time option). Then newer APIs can be introduced in time, in > > a non break-every-program kind of way. Also, it's been proven that > > 'hardware' blitting does not need to break SDL1 API compatibility to > > use hardware accelerated APIs (Angle, SDL_gpu, [insert 4 or 5 other > > projects], ...). > > > > Having a pygame2, or whatever separate repo would also make > > maintenance harder. Since for the foreseeable future, we will likely > > need to do maintenance releases for this anyway (at least I want to!, > > and I know other users of pygame will). > > > > --- > > > > For pip uploads, they would continue to be for SDL1, until we can > > finish the SDL2 changes, and it works better. There would be no new > > additions until compatibility is mostly there. > > > > The work would progress by slowly adding in compatibility changes > > whilst keeping pygame working. By keeping the SDL2 patch set as is, > > and slowly reducing the patch set until it is size zero. So we always > > have a pygame with sdl2, and a pygame with sdl1 that is producible. > > Eventually the patch set will disappear. > > > > --- > > > > A pygame2 module would just cause confusion amongst users, and that > > really boring 'pygame 1 or pygame 2' type debate would go on, and on > > like the "python 2, verses python 3" one did. For me, just avoiding > > that discussion for the next decade would be worth it. > > > > Then there would need to be two sets of documentation on the website. > > And two sets of tutorials... and... we'd have 2 of everything to *do*, > > and 2 of everything for people to look at. > > > > Finally, "import pygame2" looks kind of weird. I've grown used to > > "import pygame". > > > > ... > > > > > > > > I'm keen to get moving on this. I've been trying to get feedback on > > the 'pygame sdl2 addition' issue for the last month, and the issue has > > been open since 2013. So I'd like to put a time limit on this decision > > for one more week. > > > > I'd really like to hear back from contributors, and users (everyone). > > > > > > > > > > ps. Interestingly SDL_gfx has an SDL2 release now. > > http://www.ferzkopp.net/wordpress/2016/01/02/sdl_gfx-sdl2_gfx/ > > > >
