Re: [pygame] Pygame's future beyond 1.8

[Alex Holkner <aholkner@xxxxxxxxxxxxxx>]

Rikard Bosnjakovic wrote:

> This is no flamebait or whatsoever, rather an ignorant nature on mine,
> but I must admit that despite lots of posts in here and reading on
> both http://www.pygame.org/ctypes/ and
> http://starship.python.net/crew/theller/ctypes/ I have absolutely no
> clue what the point of this "ctypes"-thing is and what's so good about
> it and why it's implemented/ported/whatever-it-is to pygame.
>
> So, what's the (good) point with it?

The biggest advantages will come in the long term (think years, not months):

The current implementation of Python is very slow.  There are a number 
of efforts to reimplement Python using very different backends; for example:

* Jython uses the Java virtual machine
* IronPython uses the .NET common language runtime
* PyPy (among many other things) is targeting native machine code, both 
statically compiled and runtime compiled. 

None of these projects will ever be compatible with the existing Python 
extension mechanism, which is closely tied to its implementation.  
ctypes is the "missing link" that allows these new implementations to 
support external libraries without the need for extension libraries.  In 
the distant future, extensions such as Pygame will not be useable, as 
most people will be using a newer implementation of Python.

Pygame-ctypes is our long-term strategy for getting ready for this 
inevitable change.  Other projects such as PyOpenGL are undertaking 
similar efforts.  Why are we getting started so early?  Well, the 
opportunity came up for Google to bankroll this initial phase, so we let 
them :-)

There are some short to medium-term advantages too:

* Pygame-ctypes is simpler than Pygame: the code is around 5,000 lines 
versus Pygame's 20,000.  This makes it a lot easier to maintain (and 
it's in Python, instead of C!)
* Hacking Pygame-ctypes is easy: you don't need any knowledge of C or 
the rather complex Python extension mechanism.  Expect to see more 
people providing features and patches.
* For example, there is already support for additional array modules 
(numpy and numarray) and closer integration with PIL (Python Imaging 
Library), allowing you to load and save more image types.
* Debugging Pygame-ctypes is easy, as it's all Python code you get 
tracebacks all the way to
the source of the error.  This is not possible in Pygame, which can be 
difficult to debug even with something like gdb.
* You now have access to all of SDL, not just the features that Pygame 
exports.  This gives you access to more advanced features when you need 
them.
* Reimplementing Pygame has effectively been an audit for the existing 
Pygame code base, and has uncovered several bugs and documentation errors.

Even in its current, unoptimised form, Pygame-ctypes is able to run most 
Pygame games at their usual framerates, though perhaps with a longer 
loading time.  There are some games (for example, most of Phil's!) that 
do not yet perform well.

The current debate is about when, or if, Pygame-ctypes should replace 
Pygame.  In my estimation, the perfomance problem will be solved in less 
than a year, by implementing parts of Pygame-ctypes in C or Pyrex.  No, 
this doesn't defeat the purpose of using ctypes: as well as an 
intermediate measure while we wait for PyPy and friends to mature, it 
still allows Pygame-ctypes to be used from these newer implementations 
(as we are not using the extension mechanism).

Alex.