I worked long and hard on my two presentations and the audience was extremely appreciative. Many people came up to me during the rest of the conference and said how much they enjoyed both the keynote and the metaprogramming talk. It really makes it worth your efforts to know you've made a difference.

I also sat on a panel chaired by Steve Holden about open-spaces style conferences. The other two panelists had primarily worked with Bar Camps, but you could tell from their enthusiasm that they'd had the same experience I have, of the magic of letting go and allowing everyone to create the best conference possible. Naturally, the first thing we did was pull chairs into a circle and turn the thing into (almost) a conversation (since we were primarily answering questions). I immediately noticed the change in feeling from "presenting to an audience" to the connectedness of having a discussion. As much as I enjoy speaking to an audience, once you've experienced an open-spaces style event, you don't want to do anything else.

All the "eyes-forward" (non-open-spaces) presentations have audio recordings and the slides are downloadable; see the EuroPython site for availability.

Originally more space was available for open-spaces sessions but the conference unexpectedly expanded with more talks and more people so we were limited to one room (but in the spirit of open spaces, we got creative and appropriated any other spaces we could find as necessary). Because of the down economy, the organizers (this is a community-organized conference, all volunteer) expected less than 380 people, but got over 430, a tribute to both the growing popularity of Python and the low cost and high appeal of user-organized conferences. Indeed, whether or not the economy improves next year it looks like the conference will outgrow the venue; it was already tight (like Pycon in the US, the pattern seems to be to reserve a space for two years at a time, apparently for economic advantages).

Steve Holden (head of the PSF, the Python Software Foundation) and I spontaneously decided that I should shoehorn my short Introduction to Open Spaces in at the front of my keynote because the open spaces started right afterwards and hadn't had a lot of entries. Whether because of that or the nature of the conference, they filled and often overflowed. I ended up attending two very valuable sessions and by request held a session called "So You Want to Write a Book" about the perils and difficulties of book publishing.

The first open-spaces session I attended was on the MoinMoin wiki system. It appeared that the whole core team was in attendance, willing to answer any questions, and it pretty much convinced me that I should move the Python book over to MoinMoin, even if it means changing the markup. The barriers to entry have been too great so far. Despite having around 100 volunteers, using Sphinx and Mercurial create too much of a hurdle for most people to contribute, and I suspect it makes contributing seem too "intimidating and important," so it isn't moving forward the way I want. Converting to a wiki will, I think, put it much more into the hands of the group and unstick the project.

The second open-spaces session I attended was on Kamaelia, which is a very different approach to solving the concurrency challenge. This was convened by Kamaelia's creator. The question he asked was at the other end of the spectrum from things like "how do we prevent deadlock?" Instead, it was "what programming model is easiest for people to grasp and use" (which, of course, is the Pythonic way to look at the problem). His observation was that people make very effective use of Unix pipes and filters without knowing anything about concurrency, so Kamaelia is a system that allows you to create concurrent "filter" components with an easy way to wire such components together in sequence and in parallel. I found this approach quite compelling; one particularly attractive aspect is the ability to quickly wire together components for rapid testing and partial system building. Right now Kamaelia's concurrency is all process-based, but the use of threads (which would still be isolated like processes, but would just utilize threads if it helped performance) is a future consideration. I think Kamaelia is worth further exploration.

The other session that stood out to me was Mark Ramm's overview of TurboGears 2, which was recently released. TurboGears takes the attitude that creating all the individual components of a web framework is too hard and that you can't get the best results that way. Instead, best-of-breed components are selected from what's out there by discovering the superior work that people have accomplished by specializing in a particular arena; an outstanding example is SQLAlchemy, which continues to look like the best object-relational mapping that anyone has created. By using WSGI (Web Services Gateway Interface, part of recent Python releases) in TurboGears 2, swapping components in and out is even easier, and that's what they've done -- out of the box, the group of components is the best for most projects, but you can easily change out a component if the default doesn't meet your needs. I've dabbled a bit with TurboGears 1 in the past, but Mark's presentation has rekindled my interest. I need to find Python hosting for MoinMoin, so perhaps this will give me the opportunity to use TurboGears as well.

One thing I found puzzling was that the Brits consistently apologized for and/or denigrated Birmingham. I didn't find it unpleasant at all; parts were quite attractive and charming. Maybe if you live in Europe it raises your expectations for a place.

PS: I'm posting this from inside the RailAir bus on the way from the Reading train station to Heathrow. Having wireless on a bus is pretty cool, but by using it I'm not paying attention to the beautiful English countryside so it's a mixed benefit.