Three-quarters of the way through the first day of the PyCon sessions, it’s already been an exciting and enlightening experience. Mitch Kapor, most recently of the OSAF, presented the keynote to start the day. I found it particularly interesting that he acknowledged up front that he stands in awe of developers and coders. Mitch spoke of attending a summer program for budding astronomers in 1966. A computer, a Bendix G10, was available, and while he was able to make it perform basic computations and tasks, there were other students there who would stay up all night hacking it to calculate comet tragetories and orbits. Here’s what he said:
“What I learned was that while I was fascinated by computers, there were people who had something I didn’t have: some kind of skills, patience, and who by writing code could get computers to do amazing things. And I realized I wasn’t that sort of person, but I admired them.”
The sessions I attended this morning were book-ended by two presentations of web development: mod_python and Quixote. I attended the mod_python session to gain background on exactly what it entails and how it could possibly be used. I took two things away from the presentation. First, mod_python seems better suited for customizing Apache than developing web applications. It includes PSP (ostensibly Python Server Pages), but it’s real power seems to come from the hooks it exposes for the Apache request serving process. I can much easier imagine “fixing” mod_rewrite than developing an entire application using mod_python. The second point I took away (or maybe was just reminded of) is that Tufte is right.
The last session of the morning was an overview of Quixote. I’ve experimented with Quixote in the past, but never worked with it enough to develop a full fledged application. At the session Quixote’s form framework was demonstrated, which impressed me with it’s simplicity and clarity. While not exactly the same, it definitly shares some philosophy with Zope 3’s schema-based form generation. It was interesting that both mod_python and Quixote developers acknowledged inspiration from Zope, and stated that the need for something lighter weight drove their development. I think the advent of Zope 3 will help remove that perceived weight: Z3 will still have the powerful mechanisms of Zope 2, but they’ll be exposed in a much more Pythonic way. This of course raises the question about where the line between the Zope 3 and Quixote problem domains lies. I suspect it has something to do with the need for content management facilities.
In between the two web sessions this morning I attended Andrew Koenig’s presentation on how Python helped him design his new kitchen. This was by far the most entertaining and most inspiring presentation of the morning. Koenig stressed the importance of using tools you have, and more importantly using tools you understand in order to solve problems. In generating the manufacturing outline for his kitchen countertop, he used pic and troff, because he knew how they worked. And he used Python to generate the input for pic, because it was possible to quickly go from thought to image, with few steps in between. The question asked of Koenig were also interesting. They demonstrated (to me, at least) that people like small (simple?) pieces of software that does a particular task and does it well. This is probably worth remembering as we developers are tempted to add functionality because “it’s really cool”.
This afternoon I started out intending to write up my experience of the morning’s presentations. I sat down in the IronPython presentation intending to tune out the speaker and found myself transfixed. IronPython is an implementation of Python on the .NET CLR. More interesting to me is the intention that IronPython should allow Python code to run on Mono when it reaches 1.0. THe use of the ECMA standard CLR means it should be possible to mix Python code with code generated in other CLR languages. This seems really exciting, since each language seems to have it’s own special niche.
The author, Jim Hugunin, started out intending to write a paper on why the CLR is so hostile to dynamic languages. He ended up determining that many basic Python constructs would actually run faster on the CLR than CPython. While IronPython is still far from ready for production use, it was amazing to watch Jim demonstrate using the Python console to import Microsoft’s Agent framework and instantiate the Merlin animated agent. While this was the only interesting use of Merlin I’ve seen, I am glad he didn’t choose Clippy.
Following Jim was the presentation of a static-type inference engine, Starkiller. Michael Salib, a graduate student at MIT, demonstrated the algorithms and system he’s using to speed up Python using type determination and inference. Michael is memorable as the most irreverent speaker yet. Some highlights:
* “because I’m from MIT I’m going to make bland assertions without backing them up with numbers” * “I’m RMS, I wrote emacs. Will you sleep with me?”
After the performance focus of the IronPython and Starkiller talks, I wandered into to hear about DEAP, a package for generic scientific data graphing analysis developed for astronomers. Nothing I’ll ever use, but I was amazed at the breadth of applications being developed in Python. Ditto for the following talk on using SimPy to model nuclear fuel manufacturing processes.
You can find the full text of the PyCon presentations online at the PyCon website.