There is also http://pygame.org/
, a layer on top of SDL.
Oh, and PyPI could be interesting as well: http://pypi.python.org/pypi?%3Aaction=s ... mit=search
By 'glue-ing' do you mean basically hooking the game scripts together?
No, hook the fast (compiled) lower level functions together. Python is interpreted, so you don't want it in your rendering engine drawing sprites, pixel by pixel.
Instead, you code the latter in some compiled language, and Python uses that code as a function it can call "render this sprite", and "this one" and so on.
Selecting the next sprite is not where the CPU time is spent, compared with rendering pixels.
If sprite selection is still too slow, code that also in some compiled language, and use Python to call that new code (which probably does something like "rendering the display for this frame") or so. Saying "render everything" is not where the CPU time is spent, compared with the actual rendering process.
For places where speed is non-relevant, eg entering a name in the high score table or so, Python can go right down to the bottom, the OS interface.
So what you get, places where speed counts get coded in a compiled language, and Python manages the composition of all these compiled blobs of code, moving data between them, and deciding what to call when.
And I have seen your FreeRCT project, may I ask what that is written in? (I assume C++)
The game is, but there is practically only engine currently, ie display of the world. There is no 'game' yet.
I have not made up my mind whether I want a scripting engine, perhaps I should slowly start thinking about it :)
I do use Python though, the RCD data files are created using Python code; it's in rcd/*.py and rcd/rcdlib/*.py. It makes use of PIL (Python Image Library), which is a compiled library for doing image manipulations.
I use it in a relatively stupid manner though, so it is not so fast :p
My project: Messing about in FreeRCT
, dev blog
, and IRC #freerct at oftc.net