summer of code students announced

It's been a stressful few weeks, but we've selected 30 students to work with the Python Software Foundation for Google's Summer of Code.

I don't know what I was thinking in volunteering to be the PSF's admin this year, but I'm happy to have had the opportunity. I believe we have more students working on core Python projects this year than all previous years and certainly a good start with getting students involved in our community.

There's a lot more work to be done; getting students setup on the SoC Python planet, getting all the backup mentors and coordinators organized, making sure students are taking advantage of the community bonding period, etc.

PySoy ended up with one student, Jo Yo (aka Lucas Westine) working on character animation. He worked with the Ogre3d team last year on a similar project. He's being mentored by Eric Stein (aka Toba) who wrote PySoy's soy.fields module as a Summer of Code student in 2007.

Building a better Pyrex - part 2

Vala, the C#'ish language from the Gnome project for building GObject-based applications, may not seem like the most intuitive choice for building Python extension modules.

For PySoy, she may be our long-sought salvation from Pyrex.

First to note, PySoy is based heavily on GLib. While much of GLib is redundant to types and functions available with Python's c-api, the GLib functions don't require Python's GIL to be used. This is what allows PySoy to take full advantage of multiple cores and run Python code in parallel with rendering and physics processing.

Second of note, as I wrote in my last post, Pyrex/Cython are not appropriate for PySoy as an overwhelming majority of our code is inside with nogil:. Many Pyrex/Cython language features, what makes them easy to work with, are thus unavailable to us. The language becomes a burden and "GIL minefield" that makes working with it difficult.

Like Pyrex, Vala "compiles" clean object-oriented code to C, unlike Pyrex we have full and direct access to all datatypes and classes without the GIL. Like Pyrex, Vala needs pseudo-headers to instruct it how to use C libraries, unlike Pyrex the .vapi files give us an OO API for working with those libraries.

This was the real deal maker though; Vala is flexible enough to use PyObject and family directly. Not only do we get GObject access but with python.vapi, full OO access to Python's c-api with automatic incref/decref and easy Python/C type conversion.