My whole EuroPython experience was a little disjointed, starting with arrival. I and one other delegate ended up on a bus that went, not to CERN but to a local railway station three or four kilometers away. The result was a late arrival, so by the time I took my place in this session Kevin was just starting to present his first example, how to adapt a simple application to the WSGI interface.
Using simple_app was the easiest, but Kevin also showed us how to do it by defining our own class. He then considered the problem of maintaining session state (though Kevin says he prefers not to use state).
WSGI is also helpful in such situations: its concept of middleware (which talks to the web server on one side and a web application on the other) can help. The example here was of a "Latinator" that translated into pig Latin. Kevin showed us how to define a class with a method that can be passed to the WSGI framework as the start_response argument. WSGI is good because there have been many contributions to the PyPI index.
Kevin next introduced us the the Paste system designed by Ian Bicking. This contains a confusing number of packages and modules, which makes it hard to describe and hard to climb the learning curve and start using it. He suggested this demonstrated that even in the Open Source world we are faced with the "build vs. buy" choice, even though "buy" is really an investment in learning someone else's package and build, as usual, is learning and understanding the base technologies you want to implement, and writing your own implementation.
In TurboGears Kevin made the choice to use as much existing technology as was practicable.
The fictitious web package author might decide to package up other dependencies, but this can cause problems for people with other versions of the components she chooses to bundle. This is the classic version dependency. The setuptools system has defined a cross-platform format for installation of Python packages, the .egg format. This can also be used to install packages with binary components, and is proving to be very usable.
The .egg format allows other systems to read the metadata about the package, which is useful in many environments where plugins are used, even in non-Python environments such as Eclipse. The discussion about how entry points were defined to plugins didn't seem terribly easy to understand to me - maybe I was just distracted by the extraneous materials, but I didn't really see the point.
Kevin closed by talking about Beaker, starting by showing us theat it depended on the MyghtyUtils package and defined two paste entry points. The examples at this stage started to leave me wishing I had attended the AJAX session instead, but this could just be me: others might have found the material relevant to their interests.
This presentation relied for contrast on rather too much use of "humourous" slides: a picture of an egg when talking about eggs, a picture of an RJ45 plug in a socket when talking about plugins. I have no objection to such devices, but they should either enhance understanding or be shown for a very short time to give everyone a quick smile before moving on.
Kevin knows his stuff and is always an engaging speaker. A tour de force, though, should really be allocated an hour, and I suspect this session should have covered more ground in less detail or vice versa.