The PyGTK hackfest is happening at the OLPC office in Cambridge, and we’ve had some productive discussions so far. There are two major orthogonal changes happening simultaneously.

Python 3

First, Python 3 support for interacting with the GTK+ stack. As far as I understand it, the Python 3 work is mostly mechanical and uninteresting, so I won’t say much more about it. There’s just a lot of code that needs to be changed.

Introspection

Second, pushing forward the new PyGI stack which among other things is significantly more memory efficient.

So there are two Python binding stacks now with different tradeoffs. In pictures, here are their respective architectures:

PyGTK

In PyGTK, a large C library is generated which bridges the two worlds, which combines hand-written “overrides” with some metadata (.defs file) about the C library.

PyGI

In PyGI, everything is done dynamically based on the information from the .typelib file. There are a very few custom overrides.

PyGTK-on-PyGI

This is our current concept; in the combined architecture, the API people are used to from PyGTK is preserved, however we begin to “hollow out” the core so that for more of the simple functions that aren’t overridden, instead of generating a static C blob for them, we look up dynamically through PyGI. This would be relatively straightforward to do on a per-function level by adding a hook in the metaclass or __getattr__. More complex would be doing this on a whole-class level, however this would also be the biggest win in terms of memory usage which is important for everyone, but particularly for Sugar.

More updates as we hack them. If you’re interested you can join us!