Europython: Kevin Dangoor - Working together on the web¶

Kevin build an RSS newsreader while recovering from perl and java: in python. There's a lot of stuff available in python, it comes with batteries included. Everything that was in ruby on rails (which he also looked at) was already available in python, it just wasn't packaged together like rails.

Two additional big plusses for python:

• Mark Pilgrim's feedparser. No worries about RSS formats.
• Handy py2exe, py2app application bundlers.

Kevin introduces a hypothetical programmer "J" that wants to build a virtual circus. Hey, you need an example :-)

Kevin convinces J to not write his own framework. Python has the WSGI module, so J can concentrate on the circus instead of writing a webserver: he only has to adapt to WSGI (pronounced "wiskey" according to Kevin).

Next up is some state-persisting, so talking to databases: middleware. WSGI has interfaces for that, so he can go to the cheese shop and search for WSGI and pick out a module to his liking and start implementing his end of the WSGI interface.

J can use python Paste to plug various WSGI parts into eachother. Paste is sort of an application generator. Look at that if you need something like that.

Is it worth learning all of those things yourselves or are you better off taking an exising library?

For Turbogears he did build the widget/form system himself as he couldn't find anything that fit in nicely with the rest of his system (he wanted to use the KID template language).

Packaging can also be a big task. Lots of different OSs, especially with pyhton. If J packages everything into one big tarball, he'll have some happy users, but others will complain about module version mismatches with their already installed stuff. RPMs get some linux users happy, but leaves windows out, etc.

Solution: setuptools, easyinstall and eggs. (Reinout: yes, works nicely). It is a sort of debian version/library management system for python modules that allows you to easily distribute your modules. You can have dependecies on other modules, including requirements for minimum or maximum versions of those modules.

Also handy: eggs can have "entry points" for plugins. One egg defines an entry point, other eggs then can provide plugins for those entry points. Plug and play. For instance, the KID template languages registers itself into the python.templating.engines entry point. Using a plugin isn't hard, the work is in figuring out what you want to do with it.

Back to the circus. J did choose Beaker as his way of handling persistence (in this case for sessions). Beaker registers itself with easyinstall as a plugin for WSGI's persistence interfaces. Beaker requires the myghtyutils module for handling sessions itself, but that's just one install_requires=["MyghtyUtils"] line in your egg file away.

Kevin: "no talk about web applications in python is complete without talking about zope3 :-)". Zope3 is about reusing existing code, so install_requires=["zope.interfaces", "zope.even_more], as zope3 has packaged most of their stuff as eggs. Jim Fulton mentioned that zope3 is also a WSGI app.

Conclusion. Kevin doesn't want to discourage people to build their own better templating systems, but then don't write your own parser, there are many of those. If you think the existing web frameworks are crazy, by all means build a new one, but then don't write your own webserver, session handling, etc.