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:
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.
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:
http://docs.python.org/dev/3.0/whatsnew/3.0.html
One 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 question
Regards,
Gregor
http://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
<[EMAIL PROTECTED]>
