Hi Gregor,If having SVN commit privileges makes one 'official' then I can try and answer your question. I build the Windows binaries for Pygame and the biggest hurdle in porting to Python 2.6, and Python 3.0, is the new C runtime library it uses. This library does goofy things to prevent unlawful use except with the Microsoft provided Visual Studio 2008. Unfortunately this causes problems in building the support libraries used by Pygame, which were developed in Unix and are most naturally built with Unix tools. I have managed it, but don't know if newer versions of these libraries will break my build system.
For Unix based operating systems, where the C compiler and runtime libraries are part of the distribution, this is not a problem. It is just a matter of someone downloading Python 2.6 and the Pygame source bundle, then running the setup script. It should build cleanly.If I had access to a linux machine I would do it myself. So I expect the move to Python 3.0 be done in Unix first, then attempt to build in Windows.
Modifying the Pygame's Python modules for Python 3.0 would be only a moderate project. For the most part 3.0 removes duplication. Here though, I think the big issue will be Unicode strings. Pygame generally just assumes everything is ascii. All Python code will have to be read, with appropriate encodes and decodes added. These changes will not be backward compatible. As for the '/' division operator, that is like the year 2000 problem. Everyone saw it coming. So if anyone still does a float division without the appropriate future statement deserves any grief this will cause.
The time consuming part will be the the Pygame extension modules. The C api will change with Python 3.0. It looks like major modifications here for every module. And unlike the Python code I know of no automatic tool to help out. Most changes are not backward compatible. Module state moves to a dynamically allocated structure. And of course there is Unicode again. All string handling code will have to be modified, more encodings and decodings.
So to get to the real question of when will the move happen? First Python 3.0 will have to show itself to be stable. Second, there is the much anticipated release of SDL 1.3. This will add long desired features like multiple windows. It also means a major overhaul of Pygame. It would complicate matters having two Pygame branches at this point. So the best answer I can give is, after SDL 1.3 is released.
Lenard Gregor Lingl wrote:
Ron Dippold schrieb:I wouldn't take this for granted, as Python 3.0 will not be compatible to 2.6 any more. Things that changed are described here, for instance:Hi Gregor,I'm not officially involved at all (thanks, Phil!) but pygame 1.8.1 has already been ported to python 2.6, which means it should be an easy port (if there's any more work involved at all) to 3.0 when it's released.http://docs.python.org/dev/3.0/whatsnew/3.0.htmlOne particular change that almost certainly will make problems (if not with pygame itself at least with some pygame applications) is the change of the division operator: 3/2 return a float in Python 3.0. If you need an integer you have to use 3//2. That means, that games that you have written for Python 2.6 or earlier will not necessarily run under Python 3.0 and thus will also have to be ported to 3.0 (if one decides to use this new version). On the other side the Python 2.x branch will be maintained for several years from now and there are also plans to release a 2.7 and probably a 2.8 in the future.So perhaps someone who is 'officially involved' could answer my original questionRegards, Gregorhttp://pygame.org/download.shtml Ron Gregor Lingl wrote:does anybody know if there are plans to port Pygame to Python 3.0, which is going to be released in the near future (approx. beginning of December; now there is release candidate 1)
-- Lenard Lindstrom <len-l@xxxxxxxxx>