This is a day-by-day account of the Eighth Python Conference, held in Arlington, Virginia in January 2000. Originally this was a set of entries in my diary for January 2000.
Tue Jan 25 2000: IPC8, day 1: The first full day of the Eighth Python Conference was marked by over a foot of snow getting dumped on the DC area. Luckily IPC8 was only a single Metro stop away from my apartment, so getting there wasn't too much trouble, and walking through the blowing snow reminded me of how much I enjoyed walking through snowstorms: the muffled car sounds, the snow-filled air, the feather-light touches of snowflakes on your face... it's great!
Eric S. Raymond was the first keynote speaker, presenting his Magic Cauldron talk. There were a few exceptionally critical audience members, who pointed out some significant oversights in various arguments. As an example of an objection: at one point ESR claimed that, when current software businesses charge for software up-front and provide free support, this loses money because the potential cost of support is infinite. Someone pointed out that you can invest the money collected up-front, and the interest might be enough to pay for ongoing support costs.
Like ESR's other papers, The Magic Cauldron is persuasive but also seems faintly dodgy; you get the feeling there are counterarguments that aren't being mentioned. (On the other hand, often when people bring up counterarguments to their own position, the subtext is often "I have an answer to this objection that's really good, so I'll now raise it.") Whatever the merits of the paper, it made for a lively and argumentative discussion.
The two conference tracks are for Python and Zope, and I'll
mostly be attending the Python track. The first session in the
Python track was "Python Futures", with 3 papers related to
language design issues. Talk #1 was Greg Ward's "Introduction
to the Distutils", which covered the current state of the
Distutils-SIG. The Distutils effort is aiming at producing a simple
way to install Python packages; you'd run python setup.py
install and everything would get compiled and installed; you
could also run 'build', 'build_py', 'dist', etc. Greg's a pretty
good informal speaker, and the talk covered most of the territory
about how the Distutils code runs commands and looked at some
sample setup.py. I suspect that it would have been
better to spend more time looking at writing the
setup.py file, and less on the more advanced area of
adding new commands, but the audience reaction was still quite
favorable, and, as usual at Python conferences, there was lots of
audience response and feedback.
I've already started using the Distutils for packaging my Python software; while it's only at version 0.1.3 at the moment, it can readily handle distributions that contain only Python modules. Packages with C code, such as the XML package, can be handled pretty well on Unix; I expect portability to Windows or Mac are still problematic. The only way to find the remaining problems is for people to pick up the code and start using it to package their software; they'll run into bugs and blank spots. Everyone got that?
Second was John
Aycock's "Aggressive Type Inference" (right), in which he
implemented a type inferencing system for Python, and then checked
its accuracy on a number of sizable programs such as Idle, Gadfly,
and Grail. This confirmed Aycock's hypothesis that most variables
in Python programs can have a consistent type inferred for them;
programmers rarely use the same variable name for both a list and
an integer, and such polymorphism is usually confined to a few
sections of code. Aycock's primary motivating example was
translating Python code into Perl, though it's also applicable to
translating Python into C or Java bytecodes. (GvR jokingly accused
Aycock of choosing this example "for shock value".) Consider this
Python code:
L = [1,2,3] a = L[0] + 4
The Perl equivalent would be something like:
@L = (1,2,3); $a = $L[0] + 4;
Because Perl's variable naming makes a distinction between lists
and scalars, a translator would have to be able to infer that
L only holds a list, and a only holds an
integer.
"Aggressive" means "sometimes wrong".-- John Aycock, IPC8
Finally, Christian Tismer made his "Stackless Python"
presentation. The current CPython code does a C function recursion
for every Python function call (in eval_code2() in
Python/ceval.c), which means that you can only recurse
so deeply before filling up the C stack. Stackless Python
does some major surgery on ceval.c to dynamically
allocate stack frames. This has many pleasant side effects: with
this change, you can then implement continuations, generators,
co-routines, microthreads; Christian even suggested that it would
be possible to pickle an entire interpreter state, ship it
somewhere else for unpickling, and resume the thread of
execution.
The major problem with the talk was that the project is really fascinating, but also really hard to explain; Christian hasn't yet figured out the right way to explain the project, or applications for continuations, so that their usefulness is readily apparent. It's also difficult to explain the implementation details clearly; the idea of a tree of stack frames, instead of a linked list, is a bit foreign to most programmers familiar with imperative programming. This isn't surprising, though, and is no slam against Christian, because it's a complicated topic and structuring an understandable explanation is difficult. Annoyingly, GvR seems cool to the idea of incorporating the Stackless patches into Python, though that might just be due to lack of information; I don't know if he's actually looked at the modified code yet.
After a brief break, I switched over to the Zope track to see the Portal Toolkit presentation. The demo didn't seem to be much more advanced than the slides available on zope.org, but at least it *is* actually running now! The next talk, "Reusing and Evolving Application Frameworks in Zope" by Phillip Eby, was the highlight of the session. Greg Ward and I have speculated about writing a document to be titled "Elements of Zope Style", because programming a Zope application isn't like writing an application in Python or any other regular programming language. Instead, you're stitching together fragments of DTML and SQL and Python, and values can be coming from Web forms or folder properties or other DTML methods; the flexibility is much greater, and the tools you have for structuring a set of code are weaker.
Greg and I haven't written that document, and can't yet propose any stylistic guidelines, because we don't have enough experience yet. Digital Creations has probably evolved internal principles and patterns from their consulting work, but I haven't seen any documents from them that cover this topic. Anyway, Eby's talk proposed 5 Zope patterns -- Application, Rack, Implementor, PropertyHandler, and Predicates -- for structuring a set of code, and for creating frameworks that can be made to interoperate. This is the first attempt I've seen at evolving principles for Zope design, and it's a promising one; a bunch of lightbulbs went off over my head during the talk, and I'm going to look at our Zope code with new eyes. The PowerPoint slides from the presentation are available from Eby's member area on Zope.org. Eby and Ty Sarna both work for Verio, a large ISP which has acquired 50 or so smaller ISPs, and their job is providing interfaces to all the legacy billing and user management systems, so they've obviously had a lot of chances to notice repeated patterns.
Next came GvR's keynote speech about Computer Programming For Everybody, but it was preceded by 3 brief but interesting announcements. First, Greg Wilson talked about the Software Carpentery competition. Provocatively, he said the competition has arisen from what he called "the impending collapse" of current supercomputing, as the apps get moved to Linux clusters and traditional supercomputer vendors go out of business. SC aims to create newer, easier-to-use and more powerful tools, and to introduce the free software community to the supercomputing community, "who have unlimited money and real problems."
Next was Dick Hardt of ActiveState. ActiveState provides commercial support for Perl, and also has contributed most of the Perl Windows port. They're now going to be adding Python to their menu of services, providing pre-packaged Python for Windows, Linux, and Solaris (presumably this is much more than just the standard distribution, and they'd include Numeric, XML tools, or whatever). They've definitely started off on the right foot, hiring Mark Hammond (author of Pythonwin, co-author of the Python Win32 book) and David Ascher (PyOpenGL, NumPy for a while, and also an author) and joining the Python Consortium. Since they've got two highly skilled developers, I expect to see interesting Python-related things coming out of ActiveState before too long.
Al Vezza was third, with a quick update on the Python Consortium. It's grown to 2 full members (LLNL, HP) and 7 associate members (Digital Creations, Interet, Foretec, ASTi, BeOpen, Secret Labs, and ActiveState). They've also changed the contract for joining; originally, members would get access to new Python releases 6 months before everyone else, but now code will be released simultaneously to both Consortium members and the general public.
Al also talked about the next Python conference, which will likely be in the DC area in November. The reason for having it in the DC area again is that a hotel will be easy to line up: IPC8 was originally supposed to have been at the brand-new Alexandria Hilton in December, but the hotel, originally planned to be finished in time, was still under construction in December. This meant the conference had to be moved, and I expect the Hilton's management will give IPC9 a break on pricing as compensation for the inconvenience.
Back to the CP4E keynote. If Xerox Parc's vision (and Microsoft's) vision statement is "A computer on every desktop", CP4E's vision is "Everybody a programmer". The intention is to enable users to customize their systems and solve their problems, by teaching them the basics of programming. This doesn't mean that everyone would be able to write kernel code, but rather that they could use a documented API to add some useful behaviour to a system.
CP4E will, obviously, try to use Python for this task by creating a sophisticated programming environment that helps out novices, writing a CS curriculum, and perhaps modifying the Python language to make it easier to learn. At this point, GvR used the example of case-insensitivity, as suggested by the experience of Randy Pausch's group, and asked the audience what their reaction would be to making Python case-insensitive. Some people liked the idea, others hated it, and it looks like this might become a new religious issue surrounding the design of Python 3000.
Oh, yes... Python 3000 appears to be the new name for what we've been calling Python 2.0, the non-backward compatible major revision to Python that's been floating off in the misty future. Originally I thought the name Python 3000 was a joke when GvR used it on the python-dev mailing list, but during the talk GvR said calling it "Python 2.0" or "Python 1.whatever" would be boring, and "Python 3000" was its new name. He even asked "Is anyone here familiar with the TV show Mystery Science Theatre 3000?", which warmed my heart. Python 3000 is probably going to be the first language named after two great comedy shows!
At the moment GvR is gearing up to start work on CP4E, thinking about incremental parsing and type inferencing, figuring out what to teach in one semester, and what improvements need to be made to IDLE. GvR would like a spell-checker style mode of operation for the teaching environment, so as soon as you type a line of code, it would be checked and possible problems noted. Funding is a problem, though; they've got funding from DARPA for one year, with a possible extension for one more year. Getting a full five years of funding is unlikely, and they'll explore alternative funding sources such as the National Science Foundation, or maybe even Bill Gates's educational foundation. (Which would be ironic...)
The final technical event of the day was the demo session, but I spent almost all of it talking to various people, and didn't see many of the demos. I caught a glimpse of Paul Prescod's demo, which took XML input and produced a PowerPoint presentation using PP's COM interface, and glanced briefly at PDFgen and WorldPilot, both of which seem potentially quite useful for the MEMS Exchange. PDFgen if we ever want nicely printed versions of runcards, notebooks, or whatever; WorldPilot includes a Web-based calendaring system that would save me the trouble of writing one.
Day 1 ended with the reception, held up in the 14th floor ballroom with a great view of Arlington and downtown Washington. Barry Warsaw's band, Cravin' Dogs, played, and Eric S. Raymond sat in with his flute for a few songs, and turned out to be a pretty good flautist, too. I didn't bother taking any pictures because, judging by all the camera flashes going off, there are going to be plenty of photos of this momentous occasion. I also won a free Cravin' Dogs CD by identifying the mythological source of one song's title, "Penelope's Tapestry". (It's from the Odyssey, of course. Penelope is the wife of Odysseus, and promises to marry her suitors when she's finished weaving a tapestry; each night she unravels her day's weaving as a delaying tactic. Surprisingly, I was told they usually make this offer during their concerts, and hardly anyone gets the reference.)
(Online photos: Robin Friedrich.)
Wed Jan 26 2000: IPC8, day 2: The DC area is still digging out from underneath the storm; the federal government is closed, though CNRI isn't, and so are most of the schools. The snow also resulted in day 2's schedule getting rearranged, because Randy Pausch, originally scheduled for 8:30AM, wasn't going to be arriving before noon.
Instead, Hadar Pedhazur's talk on "Venture Capital and Open Source" was moved from the afternoon. Quite a chatty presentation, with a summary of Pedhazur's background, the process of releasing Zope as free software, and other anecdotes, but not a lot of content that I found interesting.
Back to the Zope track in the morning, for the "Zope Futures" talk, Jim Fulton's "Zope Architecture" talk, and some other papers that I skipped out on. The architecture talk was pretty familiar territory to me since I've been poking around in Zope for quite a while, though it was probably quite educational for new Zope users. I regretted missing Frank Stajano's talk going on in the other room (Frank was really entertaining at IPC7) and the high school teaching talk by Jeffrey Elkner; I later heard that both were quite good.
For the past few years, it's been traditional to have a bunch of scientific programming papers at Python conferences, and IPC8 was no exception.
The only numeric talk that I saw in its entirety was "Using Python to Modernize Astronomical Software", by Richard White and Perry Greenfield. The authors work for the Space Telescope Science Institute in Baltimore, which is responsible for processing data from the Hubble Space Telescope. They use an astronomical software environment called IRAF, consisting of around a million lines of code. IRAF provides a portable, though not very featureful, environment for writing analysis software, but the command language isn't very flexible or easy to use. They started down the path of writing their own new language, but then found Python and decided to use it. (This is the canonical story told in scientific programming papers at IPC8: group has existing body of numeric routines, group decides to write a scripting language for whatever reason, group finds Python and decides to avoid re-inventing the wheel.) Because IRAF works by running subprocesses for each job, Python only needs to be able to speak the fairly complex interprocess protocol in order to fit into the system. The Python interface, called PyRAF, will soon be going into beta testing at a few sites, for final release in a few months; it can parse and emulate the old command language, too.
I saw only part of Joseph VanAndel's "Lessons Learned in Developing PERP", and missed Paul Dubois's "Climate Data Analysis Software", because I skipped out early to go talk to some people.
The final keynote speech was Randy Pausch's talk about the Alice virtual reality system. I've seen Pausch deliver a similar talk at CNRI, and it impressed even CNRI staff, who've seen a bazillion demos in their time. Since then, Teddy's actually been integrated into Alice, and it elicited ooh's and ah's from the audience. To begin at the beginning: Alice is a 3D VR system used in a course at CMU. The audience for Alice is non-technical users who do not have a background in engineering or CS or math; accordingly, the system has been carefully tested for usability throughout its development.
Here RP told some highly amusing anecdotes, most of them scornful of the ability of programmers to empathize with normal users. For example, programmers need to be present during usability testing, because if you interview users and simply report problems later, programmers will often deny that there's actually a problem. However, since programmers are predominantly male, putting programmers in the same room is a problem when the user is young, attractive, and of the opposite sex; they're too readily helpful. The counterbalance to this is to rrequire that programmers begin any assistance with "I'm sorry for having designed such a stupid system; here's what you do..." This has the proper effect; programmers will wait for users to actually begin crying before admitting an error on their part. (This is why I'm doubtful that GNOME or KDE -- particularly the tech-obsessed GNOME project -- will produce readily usable software for a novice user.)
One slide listed the major Python stumbling blocks that Alice users often trip over. Originally RP wanted to avoid changing Python at all, but these problems proved so serious and intractable that there was no other choice but to patch them in Alice's version of Python. However, there were only 3 of them:
- Integer division: the fact that 1/3 equals 0, while 1.0/3 = .333, proves impossible to explain coherently, so they've changed Python to always use floating point numbers.
- Whitespace; Pausch didn't go into details with the problem here, so I don't know if the problem was tabs-vs-spaces or something else.
- Case-sensitivity: the distinction between a variable named 'Fred' and 'fred' was the major source of confusion. This gave rise to Guido's question yesterday about case-insensitivity in Python, and various audience members tried to argue that case-sensitivity isn't really that great a problem. Since they were arguing from a position of no data, just inner conviction, they couldn't assemble much of a case.
Pausch pointed out that having only 3 flaws is pretty good; if they'd been trying to use Java, the list of difficulties would have been much, much longer. The talk concluded with impressive video of 4 different projects done using Alice, ranging from a "Calvin and Hobbes" inspired sled ride to aerobics leading computer-generated characters. (While sitting there, it struck me that the castle in Iain Banks's novel Walking On Glass, which I'd read a few days previously, would be a really cool environment to simulate.)
As in ESR's talk yesterday, there were some audience members who tried to be critical; the difference was that ESR's critics had valid arguments, while most of the critics today were arguing out of religious convictions about one-button vs. two-button mice, case sensitivity, or whatever. It's a stunning talk that gives you hope that maybe, just maybe, these computer things can be useful to people without requiring that they wrestle crashes or master Cartesian coordinates.
Unfortunately, Alice is only available for Windows, though they're working on a Playstation port, and the resulting structural changes should also provide a MacOS port. In answer to an audience member's question, he replied that you'd have to purchase VirtualPC for the Mac; Alice is efficient enough that it will run acceptably. Therefore, instead of a Linux port you should probably just get VMware and a copy of Windows.
The last session of the conference was the short talks, presentations rigidly limited to 5 minutes. I was bouncing in and out of the room while the talks were going on, and didn't pay attention to them all. The memorable ones:
- "PDFgen", Andy Robinson: A Python package for generating PDF files on the fly; Robinson demonstrated a portfolio report that included current stock data and a graph of the portfolio's performance. Looks very nice... Robinson and Aaron Watters are starting a company, Report Labs, to provide consulting services relating to the package.
- "Embedding the MetaKit database in Python", Jean-Claude Wippler: An introduction to MetaKit. I quite like Metakit, and it's a powerful tool that deserves to be better known.
- "Design and Optimization of a Python-based Finite Element Program (PFEM)", by Jonah Lee: An interesting brief talk. Usually you'd expect that heavy number-crunching couldn't be written in Python to get reasonable performance, but Lee used Numeric Python and actually got a piece of software that performed reasonably well. No mention of a URL where you could download a copy, though.
- "Field Visualization", by Patrick Moran, briefly demonstrated an environment for doing aerodynamic calculations interactively.
- "Rapid Web Site Prototyping", by Wesley J. Chun, was a glimpse at the HTML templating language built at Four11. Four11 later got bought out by Yahoo, and as a result Python runs Yahoo's mail and mapping services.
- "Recent Changes in Mailman", by Barry Warsaw, covered changes currently in the CVS tree, such as a rewrite of the mail sending pipeline, and various ongoing projects such as internationalization.
- Ka-Ping Yee demonstrated RoundUp, a bug tracking tool he's written for internal use at ILM. It maintains a list of e-mail addresses of people interested in each bug report; people are added to the list just by CC'ing them on a response. (Light-weight mini-mailing lists that get created on the fly, in essence.) He's working on getting permission to release the code.
- Finally, David Beazley gave a brief talk, entitled "Corrupting
the Young", on teaching undergrad systems programming with Python
instead of C or some other system-level language. It must have been
a lively course; for example, students implemented TCP in Python
using a patched
socketmodule with raw socket support and root access to an isolated cluster of Linux machines. Dave's final verdict was that it was a good exercise and worked out fairly well, though Python's flexibility resulted in some rather crazily-coded TCP implementations.
An education BOF followed, but I didn't attend it.
Thu Jan 27 2000: IPC8, Developer's Day: The day started frustratingly. Though there was no new snow, today was the first day of normal work after the storm, and Metro ridership was up. Combine this with Metro having 100 cars offline from snow-related causes, and the result was incredible congestion. I sat in Court House station for an hour waiting for a train to arrive that wasn't packed solid. All the taxi services were busy, and I waited too long to start walking, so I ended up missing the introductory session (at which I was supposed to talk). Luckily Barry said my absence wasn't too much of a problem, because the session wound up being pressed for time.
I actually showed up partway through the I18N session, run by Andy Robinson. MAL's Unicode type is coming along nicely, apparently, so that shouldn't be much of a problem. Harder problems are the many different Japanese encodings, and localizing Python code and DTML methods.
Then we had the XML-SIG session, and it went pretty well; we actually came to closure on a good many issues, and decided on a list of things to do. (See my posting to the XML-SIG mailing list for the details.)
The last session I attended was Barry's JPython session. The most notable bit of news here was that O'Reilly is working on a JPython cookbook; it will contain examples of various tasks where JPython is useful, and show how a solution is implemented. They want to develop the book in an open fashion by incorporating contributions from the community. So if you're familiar with JPython, consider submitting something to the project. (No Web site yet, as far as I know, since no formal announcement has been made.)
For supper, 12 of us walked across the Key bridge in a bitingly cold wind, and went to a Thai place in Georgetown. Then it was home to pack and tidy up before leaving for Montreal the following day.