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.
| date: | 2004-03-24 15:57:53 |
|---|
| wordpress_id: | 100 |
|---|
| layout: | post |
|---|
| slug: | pycon-day-1 |
|---|
| comments: | |
|---|
| category: | geek |
|---|