Re: [pygame] What about python 3?

["René Dudfield" <renesd@xxxxxxxxx>]

Hello,


What we need to do for pygame now is get *heaps* better test coverage.


This point was rammed home in a talk given by Guido about py3k.  I've
been thinking about this over the last couple of months, and test
coverage is the main thing that we should be doing now in preparation
for python 3.  There's no point targeting python 3 yet as it's still
very liquid.  By that I mean the buffer, array, string, io modules
have all been changed heaps - and are still changing.


The C API in python 3 is supposedly not going to change that much.

Guido said that in his talk at europython at least.  The idea being
that changing both python, and the C API at the same time would be a
little disastrous.  However there are already changes to the C API, so
I think that there will actually be lots of changes.

The suggested route for packages upgrading is listed on his blog posts
about py3k, and the python 3000 pep.  It's worth reading those since
there has been some thought put into it.

However there is no transition plan for people without unit tests, and
no transition plan for C API modules.  They called people silly/stupid
who don't have unit tests.  Unfortunately for them there are many
people who don't have unit tests for all their code.  They require
people to have unit tests because the conversion tool from python2.6->
python3 can not work correctly all the time - so you need to test your
code.


The other thing we should do to prepare for python 3 is to separate
any code from the python wrapper code.  For example having the draw,
and transform code separated from the wrapper - so it's just C/SDL
code in there.  This will make it a tiny bit easier to share code
between a python3 and python2.x pygame... if we go that way.


Python 3 is still a while away, so we have plenty of time.  I think
Guido said that python3.1 is probably going to be the polished version
for python 3.  I think more people are going to prefer python2.x for
three years at least.  I mean there's still people using python2.4,
and 2.3 - so python3 uptake is probably going to take a long time.
Probably similar to the php4->php5 transition, and apache1.3->apache2
situations - and hopefully not perl 6!  But who knows?

The more interesting thing for me is the SDL 1.3 release.  Which
luckily for us, will probably happen around the time python 3 comes
out.  We will also need good test coverage for SDL 1.3.

It might be good to make pygame split the code base at the point where
SDL 1.3 and python3 are to be supported.  At least abstracting out the
parts which are different between SDL 1.3/1.2 and python2.6/3.  This
would be the point where python 3 is actually useful, and used by
people - some time in 1-2 years.

I think we want to support pygame on older pythons still - python2.3+.
 And definitely for ages after py3k comes out.  I think we should also
try and support SDL 1.2 after SDL 1.3 comes out.

I think we should investigate python3 more fully when the beta comes
out.  Until then it's a waste of time, since there is no transition
plan for C API modules yet - and they are still changing py3k a lot.
We should however prepare for it.  We should prepare for python 3 by
writing more unit tests - and separating any non python code as much
we can.  Then if/when we want to use py3k, it will be easier to do so.

A message for any python developers reading this: please give us a C
API module transition plan documenting changes to the C API.  That
will make extension writers lives much easier :)


On 9/1/07, Lamonte Harris <pyth0nc0d3r@xxxxxxxxx> wrote:
> What do we do for python 3 :S.  When will there be information on pygame and
> the new Python 3?
>
> Thanks.
>