PyCon DC 2004 was held March 24-26, 2004, (plus four days of sprints beforehand) at George Washington University in Washington, DC. The 364 registrants were a 40% increase over previous conferences. One person even came on the last day and paid the full registration ($300) fee in spite of being offered a discount, so eager was he to support Python.

This was the second attendee-run conference put on by the DC crowd. They organized it using the ultimate in iconoclast project management tools, a wiki ("the people's organizer"). MoinMoin was supplemented by a mailing list and IRC. Steve Holden, who introduced himself by saying "my name is not important", also said, "I'm responsible for this mess". Behind this classic British understatement lies a capable leader, a veteran of PyCon DC 2003. The organizers burnt the midnight oil for several months doing the thousand and one little tasks necessary to make the conference run smoothly: making this year's food better than last year's (including options for vegetarians), providing Net access within GWU's wireless policy, approving papers and scheduling tracks, running a registration Web site, scouting out low-cost hotels and restaurants, coordinating with the sponsors and more.

A few things didn't go off as planned. The paper review schedule wasn't coordinated with the registration schedule, necessitating the extension of the early-bird registration discount. Insufficient attention was given to the Open Space sessions and Lightning Talks. The GWU caterers didn't return messages as responsively as last year. Nevertheless, the show started on time, enough registrars were on hand to prevent check-in from becoming swamped, the speakers were easy to see and hear, the schedule (printed on a color printer) was easy to read and two rooms were available throughout for sprinting and BOFing.

The Python Software Foundation (PSF) was responsible financially for the conference and ran it as a fundraiser. It was extremely successful; the preliminary estimate I heard was "five figures". The reason for this was the unexpected surge in registration during the last month, due to Trevor Toenjes' marketing efforts, which netted a hundred more registrants than anticipated. The PSF now is deciding how to spend this money to pursue its mission: holding Python's intellectual property and keeping it freely available, supporting Python development and related open-source projects and promoting Python to the unconverted. Possible ideas include grants toward more action-oriented events (for example, non-conference sprints, software-project meetings) and promoting Python to project managers (mid-level managers who are somewhat clueful technically). But it will take some time to decide because the PSF is run by volunteers with their own day jobs. One of their ideas already has been implemented, though: this year's sprints were underwritten by the PSF. Guido's time machine strikes again.

Last year, Guido presented Tim Peter's "Zen of Python". This year it was on the back of everybody's T-shirt. I also learned about this little-known module in the standard library:

$ python
Python 2.3.3 (#1, Apr  6 2004, 18:13:12)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
>>>

Of course, this harkens back to the Import This! challenge of Python10 (2002). Now you can. this.py is a nice little ROT-13 puzzle for the YAPyH's out there. Those holding out for this to replace self someday, however, may be disappointed.

So what is a sprint? A sprint is a group of people hacking together on the same software project. Some sprints require a minimum level of experience; others are open to anybody who wants to get involved. Sprinters can contribute in a wide variety of ways, not only coding (new features, troubleshooting, regression tests) but also user documentation, developer documentation, squashing bugs, brainstorming design ideas, doing a teach-in, preparing promotion materials and so on. Having several sprint groups in the same room means that whenever you need help on some esoteric topic you can shout, "Is there somebody here who's an expert on ___?", and likely there is.

2003 had twice as many sprint groups as last year. There were sprint groups for the Python core, Zope, Twisted, Chandler, Plone, Docutils and Guido van Robot (a language for teaching programming fundamentals). One side benefit of sprinting is the opportunity to see Python luminaries at work, often on projects different from what they are known for.

I participated in the Docutils sprint. I had a longstanding grudge with reST: its inability to output an HTML fragment exactly corresponding to the input text, without the HTML header and style crap around it. David Goodger, Docutils maintainer and sprint coach, said this was a symptom of a larger problem: the inability to extract the parsed parts of a document individually for any custom application. He teamed me up with Reggie Dugard, a sprinter with no experience but a keen desire to get involved. I helped Reggie design a function to return the parts, and he later finished the implementation. Other Docutils sprinters worked on output formats, integration with Epydoc and MoinMoin and a syntax for flagging indexable entries in the text.

At least one sprint group already has their sights set on EuroPython and is essentially doing a revolving sprint. They'll reconvene at the next available conference and continue where they left off, then go to the next conference and so on. Some projects apparently are getting most of their development done in these sprints. That inspired those of us in Seattle to try to host a regional sprint later this year. Our wiki link is below if you'd like to participate.

Mitch Kapor designed Lotus 1-2-3, a spreadsheet that arguably was the killer application that brought PCs into the business world in the 1980s. Later, he founded the Electronic Frontier Foundation, a watchdog group for civil liberties in cyberspace. He now runs the Open Source Applications Foundation (OSAF), whose main project is Chandler, a Python-powered personal information manager (PIM).

In the 1980s Mitch was fascinated by the Apple II. But he saw a big gap between what the Apple II, TRS-80 and PET could do vs. what people wanted them to do. Software, hardware and the Internet later evolved, GUIs appeared and evolved, but the critical parts still remain missing: computers don't do what the users want and they still require the users to be sysadmins--even those systems that claim they don't.

Mitch started considering open source in the late 90s when working as a consultant; he was forced to recommend Microsoft Exchange on NT for a five-person office. Exchange was way overkill for the situation and required introducing an NT server where none was before, but there was no feasible alternative. "The road was littered with corpses of companies that had tried to compete with Microsoft's product", he said. Mitch was familiar with free software, because Richard Stallman had lived up the street from him in the 80s and had picketed his house. At the time Mitch was torn. He felt Stallman was right, but he also had to think about his company's interests.

By the 90s, however, he began to consider developing open-source applications himself. One factor was the unexpected success of Linux. Companies now are betting mission-critical applications on non-commercial software: "The business community still hasn't appreciated how revolutionary this will be." Open source will make software in general cheaper: "There will still be a lot of paid programmers but probably fewer billionaires." It can't be contained by any one company because the entry barrier is so low. Open source is catching on in the Third World faster than in the industrialized countries: "In five years, maybe ten at most, it will be a fait accompli." Remember that, "ten to fifteen years ago large corporations never thought mainframes and terminals would be replaced by little microprocessors."

Chandler is inspired by Lotus Agenda. It's an e-mail client, calendar groupware and a contact manager; it also can handle freeform notes and other types of information. Mitch focused on e-mail because that's the center of many people's organizational life--they use their inbox as a de facto to-do list.

Mitch chose Python over Java feeling that Java (particularly Swing) was not well-designed for end-user applications. He knew about Perl but chose Python because two people convinced him that Python has better developer productivity and its flexibility would allow users to add functionality themselves later. The latter proved correct when users came up with the idea of a spiral calendar view and implemented it.

Chandler uses wxPython, Berkeley DB, dbXML, Jakarta Lucene (full-text indexing) and OpenSSL. "Python is the glue holding all these together", he said. To use Lucerne they converted its Java interface to Python.

Mitch identified two challenges Python needs to face:

Pythoneers took these challenges to heart. Guido's subsequent keynote and several of the session talks acknowledged these goals and showed how their projects will be working on them during the coming year.

Mitch also had several challenges for open source in general:

Python's creator said, "What will the future bring for Python? Darned if I know. Maybe somebody in the future can bring back the keys to my time machine." In the meantime Guido declared Python 2.2 an ex-release, said 2.3.3 is current and 2.4 will be "better, faster, and bigger". It will be faster thanks to new library modules and more C code. The latest summary of completed and planned changes is in PEP 320: Python 2.4 Release Schedule, and a gentler introduction is in "What's New in Python 2.4" (URLs below). The full details of completed changes are in the file Misc/NEWS in the Python source, and Misc/HISTORY details all the past changes since Python 0.9.0.

Guido said the current dilemmas for 2.4 are deciding on a function decorator syntax, getting people used to generator expressions and speeding up function calls by shrinking the stack frames.

A decorator is a function that takes another function as an argument and returns a modified version of that function. Python's classmethod and staticmethod builtins are decorators. Python needs a generic syntax to apply decorators in the def line, remembering that a function can have multiple decorators. Five syntaxes are under consideration:

def foo [classmethod] (cls, arg1, arg2):
    # Guido's favorite, and preferred by PyCon hand vote.
    # Disadvantage: args separated from function name.

[classmethod] def foo(cls, arg1, arg2)
    # Disadvantage: 'def' not at left column.

def [classmethod] foo(cls, arg1, arg2):
    # Disadvantage: function name not near left column.

def foo(cls, arg1, arg2) [classmethod]:
    # Disadvantage: decorator hidden behind long argument list.

def foo(cls, arg1, arg2):
    [classmethod]
    # Disadvantage: decorator not on 'def' line.

Generator expressions are like list interpolations, but they create an iterator rather than a list. That's good because usually you're going to iterate over it once anyway, so a list would waste memory. The syntax is quite unobtrusive; simply put the keywords in a normal parenthesized expression:

sum(x * 2 for x in range(10))

If there's a comma on either side, an extra pair of parentheses is required. This eliminates ambiguity in argument lists.

The long-awaited Python 3.0 has been put off again, this time until his son Orlijn goes to college (he's now 1 1/2) or until Guido retires or goes on a sabbatical. His top wishlist items for 3.0 are:

IronPython is a rewrite of Python in C# for Microsoft's Common Language Runtime. Every port of Python to a different virtual machine tests the robustness of the language and standard libraries and often reveals some efficiency tricks that can be ported back to CPython. Starkiller is discussed below; it's a statically typed C++ compiler for Python programs. PyPy is a rewrite of Python in Python. (Yes, some people actually do this.) Q&A on a variety of topics is in the SubEthaEdit notes.

Homage should be paid to last year's most controversial topic, if-then-else expressions (PEP 308). Guido did not see it as important because the if statement exists, but he was willing to add it if the community overwhelmingly favored it and agreed on a syntax. The community could do neither, so Guido rejected it forevermore.

Bruce Eckel gave a humorous talk about static vs. dynamic typing. You can read more about it in the SubEthaEdit notes and in Bruce's Web log (see Resources). He quoted Andrew Dalke's comment about typing: "If you only care if it quacks, you don't need to check that it's a duck." Bruce maintains that even with static typing you still have to do checks at runtime for things the compiler can't catch, so why obscure the code with types and casts? He thinks one's time would be better spent writing a robust automated test suite (unittest) than on debugging type casts.

To me, the three most interesting talks were those discussing Nevow, Quixote and Atop. Nevow is the successor to Twisted Woven, a high-level Web application framework. Because I've worked with Webware and Cheetah extensively, I was curious about the differences. Nevow, like most other non-PSP/PHP servers, is based on servlets. Something parses the URL and invokes a servlet instance somewhere, and a servlet method returns or writes the HTML output. In Webware, that something that parses the URL is Webware itself. In Nevow, as in twisted.web that I described last year, your application class registers itself as the manager of a certain URL part (=directory), and then your

.locateChild(self, request, parts) 

method has to handle or delegate everything to the right of that part.

Nevow's most intriguing aspect is its built-in model-view-controller (MVC) framework, which strictly separates generic logic calculations (the data) from the specific view desired (the rendering). A servlet (a Page subclass) associates itself with an HTML template. The template might contain placeholder tags like this:

<span nevow:data="currentMonth" nevow:render="month">
<h1><nevow:slot name="label">Bogus label</nevow:slot></h1>
...
</span>

(Here and throughout I've used modified examples from the presentations.) Nevow sees "currentMonth" and calls a method .data_currentMonth in your servlet. That method returns some values needed in the <span>, possibly based on GET parameters or other criteria. Nevow then sees "month" and calls .render_month(self, context, data). That method receives the data returned by the previous method and fills the slot with its actual value:

context.fillSlots('label', monthName) 

This replaces the entire slot tag. Cheetah fans note that the template is not pulling values from a dictionary; rather, the method is pushing values into the template. The rendering method also can extract another type of tag, the pattern, which it can use in a for loop to generate repetitive sections, for example, table rows.

Nevow also has some Pythonic ways to generate HTML tags (what the W3C DOM should have been but isn't), a form handler (again MVC) and an abstraction for server-client Javascript interaction.

Quixote is another Web application framework. Its servlet lookup technique is very Pythonic: you place your servlet hierarchy in an importable Python package. Quixote processes the URL parts from left to right, using getattr() to find each part. This allows wide flexibility: each part can be a submodule, class, instance or anything else that has attributes. Eventually Quixote should find something callable: a function, a method or an instance with a .__call__ method. It calls that with a request data structure, and the return value is the HTML string (or an instance of a streaming class). At each step three special attributes in the parent affect the behavior:

._q_public (list of strings, required) 

Must list the subattribute. If the subattribute is missing or ._q_public is missing, Quixote pretends it couldn't find the subattribute. That's to prevent accidentally publishing private objects.

._q_access (function/method, optional) 

May raise AccessError to forbid the request.

._q_index (function/method, optional) 

Saves the day if Quixote falls off the end of the URL without finding something callable; akin to index.html.

._q_lookup (function/method, optional) 

Wildcard attribute if no specific attribute matches; akin to Python's .__getattr__().

But the most interesting aspect of Quixote is its template system, PTL. It's useful not only in Web servlets but in a wide variety of applications. Unlike Nevow and most template systems that have placeholders in the text, PTL embeds the text as string literals in a function. For instance:

# example.ptl
def cell [html] (content):
    '<td>'
    content
    '</td>'

def ordinary():   # An ordinary Python function.
    return "Result."

To use it:

import quixote;  quixote.enable_ptl
import example
print example.cell("Acme & Co.")   # Prints "<td>Acme &amp; Co.</td>".

enable_ptl installs an import hook, which tells import how to load *.ptl files, compile them and write *.ptlc files. [html] is a decorator as described in Guido's keynote above. Because Python doesn't yet have a decorator syntax built in, PTL has to fake it. The PTL compiler captures the literal result of each expression or string--what Python's interactive mode would have printed--and concatenates them into a return value. This is something I've often wished Python or Cheetah could do, and here it is. PTL seems more suited for templates with smallish blocks of text and a lot of calculations than for templates with multi-page static text and only a few placeholders.

The [html] decorator automatically HTML-escapes expression results and arguments but does not escape literals. This is usually what you want, because results may come from an untrusted source, but literals are presumably correct. The return value is a pseudo string, an htmltext instance, used to protect it from further escaping should it be passed to another [html] function. There's also another decorator, [plain], which does all the concatenation goodies without the escaping and is suitable for your non-HTML applications.

I went to the Atop talk because the summary said BSDDB. I thought, "Well, anything about Berkeley DB will be mildly interesting." It turned out to be majorly interesting, because Atop is an object database built on top of Berkeley DB. How did they know I recently had been looking for Python object databases besides ZODB?

The session paper is not on-line, but the SubEthaEdit notes are. All serializable objects must subclass or be Item. Every item has a unique numeric ID; there's no physical nesting of objects. However, a Pool acts like a list and gives the illusion of nesting. In reality it contains pointers to the various raw items. Pools can be queried, for instance:

pool = store.getItemByID(7)  # 'store' is an open database.
for item in pool.queryIndex('name', startKey='Bob'):
    # Loop through all elements whose 'name' attribute is >= 'Bob'.
    print item.name

Berkeley DB is reliable, fast, easy to install and fully integrated with Python. Several other projects use it, including MySQL (as an optional table format) and Subversion. However, it's extremely difficult to use correctly, and the dangers include data corruption. Fortunately, Atop takes care of these problems so you don't have to.

Atop currently is distributed as part of divmod.org's Quotient package, a Twisted server that's described next.

The Twisted talk essentially was its own mini-conference. The Twisted developers turned out in force, conducting several sprints on different Twisted topics, presenting a whole track's worth of session talks (including software that can be used both with Twisted and standalone) and drawing over thirty people to their BOF.

Divmod presented its Twisted-powered commercial Web mail site, whose source code is available at divmod.org if you'd like to compete with them. divmod.org distributes Atop (discussed above), Lupy (a full-text indexer), Nevow (discussed above), Pyindex (an indexer using Metakit), Quotient (the webmail server), Reverend (a Bayesian filter) and Stoom (Voice over IP). In addition to Web mail, divmod.com provides POP/IMAP access, integrated spamfiltering (you can override the Bayesian score), flexible searching (by phone number, URL, image, or "question" in the message), blogging, an image manager, contact list, calendar, to-do list and Internet phone (VoIP). They're working on blog-via-email and also multiplayer games. The cost will be somewhere under $10/month for Web mail and basic services, with additional fees for VoIP-to-landline, advanced games and the rest. As an open-source project, divmod.com also will be soliciting feature contributions from its users. A few attendees wondered what Chandler is trying to do that divmod.com isn't already doing. However, I couldn't find a link on divmod.com to sign up. Maybe signup-via-web is not quite ready yet, or maybe it needs a big "subscribe!" button.

Twisted is amazingly flexible and Pythonic, but that darn asynchronous event loop makes thread-happy people run in terror. You can't simply call functions that block, because blocking halts the entire server and makes everybody else's request wait. So you have to turn your program inside out to avoid blocking. Last conference I got excited about Twisted, and every few months thereafter I tried to understand this inside-out method of programming, but every time I hit a brick wall. Now, after talking with the developers at this conference (Donovan Preston, Nevow's inventor, was especially helpful) and reading the Deferred HOWTO three friggin' times, I think I'm finally getting somewhere.

First, there's probably a Twisted library for everything you need to do, so you can avoid the issue for a long time. Second, you mentally have to divide your code into chunks at the natural blocking points. Each chunk becomes a separate function, and you use callLater or addCallback to switch to the next function. This implies that for each blocking point you have to wrap two sections of code into functions. The first section is the slow function that runs after the pause; let's call the new function the "deferred job". The second portion is in the calling routine that depends on the slow function's return value; this is the "callback".

Let's say the slow function does a database lookup and the deferred job is the portion that comes after the I/O. The slow function uses callLater to schedule the deferred job and returns a Deferred instance (d) to the calling routine:

from twisted.internet import deferred, reactor  
# 'reactor' is the event loop instance that's running.
d = defer.Deferred()
# reactor.callLater(SECONDS_AS_FLOAT, FUNC, *args, **kw)
reactor.callLater(2.5, deferredAction, d, arg2, arg3, kwarg='value')
return d

callLater is like UNIX's at command: it schedules a background job to run at a future time. The job has no knowledge of its context, but because you can pass as many arguments as you want, it has all the info it needs. Of course, the job can be a bound method if you want to sneak in other information too. The job needs d, so pass it as an argument or sneak it in as an instance attribute.

The calling routine gets d instead of the result. How lovely, just what we didn't want. The calling routine has to register callback function(s) that will operate on the result.

d.addCallback(myCallback)
return  # Nothing more to do since I'll never get the result myself.

So d is the link between all the functions, which don't otherwise know about one another. Time passes and the deferred job is called. It produces a result and calls:

d.callback(result)   # Oh, so *that's* why I needed 'd'. 

Note: the deferred job does not return the result. d then calls all the callbacks that have been registered. The first one is called with one argument: the result. Any subsequent callbacks are called with the return value of the previous callback; this allows generic filter functions to serve as callbacks. The callbacks must completely dispose of the result by printing it or saving it somewhere, because it will be thrown away after the last callback finishes.

My two biggest hurdles with all this were, "What if the callback needs more info from the caller?" and "How does the slow function know when the result will be ready?" Let's look at these separately.

"What if the callback needs more info from the caller? I called the slow function because I wanted the result. I don't mind waiting, but why should I wait for somebody else to get the result? That's the biggest load of crap I've ever heard. I've got my local variables all nicely set, and the callback will need them." Because you can't pass arguments to the callback, you have to sneak the external data in as default values, nested-scope variables or instance attributes. If there's a lot of external data to sneak, using a bound method for the callback looks increasingly attractive.

"How does the slow function know when the result will be ready? It has to choose a certain number of seconds, but how does it know when a database query or socket read will be ready? Won't the deferred job just have to block anyway waiting for it?" The answer is so obvious I felt like a fool when I realized it. The deferred job does a non-blocking poll to see if the result is ready. If it's not, the job schedules itself to run again with all its same arguments after another interval. It avoids calling d.callback until the result is known. If the result is never known, the callbacks never are called, but that's what we want. There are optional errbacks and timeouts (which we won't discuss here) to handle exceptional situations.

The most entertaining talk was "Faster than C: Static Type Interface with Starkiller", by Michael Salib. That was only the fourth best title of the conference, however. The top three were "'Scripting Language' My Arse: Using Python for Voice over IP", by Anthony Baxter; "Flour and Water Make Bread", by David Ascher; and "Two Impromptus, or How Python Helped Us Design Our Kitchen", by Andrew Koenig.

The Starkiller talk was enjoyable because Mike is one of two speakers who doesn't pull any punches--he calls a spade a shovel. His justification for writing a Python-to-C++ compiler was, "For the 15% of applications where speed matters, Python is slow. Sure, you can write it in C++, but C++ sucks. That's why we're using Python." Which actually makes a lot of sense if you think about it.

He went on to explain how Python's dynamic features that we love so dearly is the reason Python is so hard to optimize. "Python has lots of runtime choice points, but thirty years of compiler optimization research depends on eliminating runtime choices." By "runtime choices" he's referring to the fact that a variable may change type, attributes may be added after startup and the like, and all this happens after a traditional optimizer would have finished and said sayonara. "But dynamic capability is good because Python kicks ass." So Starkiller follows the 80/20 rule by optimizing what it can and leaving the rest. In particular, it refuses to optimize functions that contain eval, exec or dynamic module loading. But that's okay because most users don't use them.

Once those cases are eliminated, we examine the assignment statements to determine the types:

x=3;  y=x;  z=y;  z=4.3   # x is int.  y is int.  z is int or float. 

The types can be traced similarly through function arguments and return values. What about polymorphic functions? Starkiller handles them the same way C++ does: by generating distinct same-name functions for all argument combinations (aka overloading). Mike offers a few benchmarks to demonstrate the speed of this approach but also cautions, "All benchmarks are lies."

If you want to play with Starkiller, you're out of luck because there's no public download yet. There actually were several talks this conference presenting software that's not yet available, either because it's not robust enough or it's waiting for legal paperwork. I didn't see that in previous conferences. A few attendees commented, "Well, it's not as useful as a talk on something that's available, but on the other hand it's good to learn about cutting-edge research as soon as possible." The conference reviewers seemed to have done their job of approving pre-alpha talks only if they covered an area that was central to Python and long on Python's wishlist. Mike had his own reason for not revealing the code. "If you kill me now, you'll never get it."

Mike offered an obligatory acknowledgment. "Who owns Starkiller? MIT! Who paid for Starkiller's development? You did! Pat yourselves on the back! Thank you, taxpayers!!!" He then begs the audience not to tell DARPA that Starkiller is a Python-to-C++ converter rather than the sun-destroying weapon they think he's building. The presentation slides have a few more zingers too; they're available under the Session Papers link on the PyConDC2004 Aftermath link in Resources.

Finally, Mike ended with an indictment of the sun. "Destroy the sun! We hatessss it! It burns! The pale yellow face mocks us, keeps us from hearing the machine. It causes global warming. It causes sunburns. DARPA says the sun is bad, it warms our enemies. It weakens our dependence on foreign oil. There's only one logical conclusion: we must destroy the sun."

Guido had one question during Q&A. He asked, "Is it difficult to have so much attitude all the time?"

(There's a discrepancy about when Guido asked that question. My notes say it was during this talk. The SubEthaEdit notes say it was during Anthony Baxter's VoIP talk, which was almost as feisty. But of course my notes are right.)

Ah yes, that VoIP talk. Voice over IP may be Python's next killer application. Internet telephony currently is growing slowly, but it has the potential to become really big when it reaches critical mass. As VoIP becomes ubiquitous, people will need a new generation of applications and phones. Stoom, which runs under Twisted, is one small step in that direction. It needs a better UI, but it proves that Python is up to the task, even though VoIP requires generating sound packets exactly 20 milliseconds apart.

By the way, the title of the VoIP paper is slightly modified from the original. It's currently "'Scripting Language' My Arse: Using Python for Voice over IP." Originally it was "'Scripting Language' My Shiny Metal Arse: Using Python for Voice over IP".

Zope 3 hasn't changed much since last year; it's just further developed. It still aims to be friendlier to application developers than Zope 2, more Pythonic, more modularized, more specific in its API use (for example, less implicit acquisition), with better documentation early and a better integration of Web-based and filesystem-based application development methods. This will make applications more portable between Zope and other environments and make individual Zope features more accessible to non-Zope applications.

The PyPy talk showed that a Python virtual machine can be written in 16,000 lines of Python. The prompt looks like this: >>>>, with one extra > for each recursive level of PyPy. PyPy is markedly slower than Python and exponentially slower recursively: the innermost interpreter interprets the code, the next interpreter interprets the interpreter interpreting the code. But the PyPy developers have faith that they eventually can make it faster than CPython.

Pyrex stands alongside ctypes as an indispensable part of the C extension writer's toolkit. Pyrex compiles ordinary Python to C, but for better optimization you can use the cdef statement to declare variables as certain C types. Expressions using those variables are compiled directly to C, bypassing Python's slow object infrastructure.

Several other talks are worth mentioning but I don't have the space. Browse the Session Papers link on PyConDC2004Aftermath site and see which topics night interest you.

A surprising number of Macintosh laptops were spotted at this conference. But then I remembered that there was a surprising number of Macintoshes at last year's conference too. Bob Ippolito gave a talk called "60 Minutes with MacPython". I haven't had a Mac since I sold my Classic in 1993 to get a machine that could run Linux, I'll spare you a clueless interpretation and refer you to the session paper and SubEthaEdit notes. Bob has some warnings about which Python to use for OS X 10.2 vs 10.3, the dreaded resource fork and more. MacPython also has libraries for Cocoa, the NeXT framework that was ported to the Mac. Bob says Cocoa is a good API; it's been around for 15 years. wxPython works on the Mac but it doesn't put the widgets in quite the correct place.

One thing I didn't realize until after the conference (when my friend Brian Dorsey pointed it out) is that many of those Mac laptops were running SubEthaEdit. SubEthaEdit is a distributed text editor; you may prefer to think of it like a multiplayer game, CVS on steroids or a real-time wiki. All the SubEthaEdit programs running in wireless range of one another get together and state which files they have open. Anybody can update anybody's document simultaneously in real time. The background color of the text shows who edited what portion. When done in a lecture hall (for instance, a talk at a Python conference), the result is the best of everybody's notes all in one. This is the next generation of notetaking and will no doubt be a staple at future Python conferences.

Some of these Mac addicts went to dinner together on the first day of the conference and started thinking, "Why don't we write an open-source equivalent to SubEthaEdit in Python?" The result is Fuse, which is partially working. The developers' mailing list stalled March 30, but a couple people checked in April 11 to say they're still working on it.

Success has its drawbacks, and the biggest one is that we may outgrow GWU next year if attendance approaches 500. The organizers are shopping for a venue that can handle a thousand people, so we won't have to move again after a couple years. We may be too late for next year because conferences normally book 18 months in advance. If we do stay at GWU one more year, we'll have to cap attendance at its capacity. Priorities for a new location include:

There are arguments both for and against remaining in DC. "lac" writes in the wiki that we can't assume that the number who attend because it's in DC are more than the number who don't attend because it's in DC. We just don't know. The West Coast has OSCON, but OSCON attracts a different clientele due to its higher price and different focus. There's a possibility of two regional conferences down the road, PyCon East and PyCon West. Is that better for the community or worse? Europe already is hosting its own conferences (EuroPython and Python UK), and maybe Asia will too.

Steve Holden has said he's willing to chair one more conference but he wants to retire after that. He's hoping to train a vice-chair next year who can take over the reigns the following year. PyCon cannot remain dependent on one person or it won't succeed long term.

Steve's greatest regret is that 50-100 people marked the volunteer box on the registration, but there was no mechanism in place to alert them when they were needed, so that manpower was lost.

There's discussion about whether to have the sprints before or after the conference, or both. The argument for after is the talks will draw new people to the same-topic sprints, and the sprinters already will know one another and maybe have decided their tasks so they can start running. The argument for before is that people will be burned out after the conference.

Open Space definitely needs better organization. Open Space, Lightning Talks and BOFs need to be planned into the schedule. Perhaps the first day's topics should be set before the conference to avoid losing that day. Also, what's the difference between an Open Space and a BOF anyway?

The brightest note is that Steve writes, "It's amazing how many people say that PyCon is the best conference they have [ever] attended, even people who are quite experienced conference-goers."

Oh and Steve, if you do step down from the chairman role, you'll still be there with your British understatement zingers, won't you?

Pythoninfo Wiki

PyConDC2004 Aftermath

SubEthaEdit Session Notes

PyCon DC 2004 Home Page

Python Home Page

Python Software Foundation

What's New in Python 2.4

Python 2.4 Release Schedule

Bruce Eckel's Weblog (the four entries for March 2004 are relevant to his keynote address)

Electronic Frontier Foundation: a watchdog group for civil liberties in cyberspace (non-Python)

PyCon DC 2003

Import This: the Tenth International Python Conference

It Fits Your Brain: the Ninth Annual International Python Conference

Chandler: a personal information manager (PIM).

divmod.com: a Twisted-powered commercial Web mail site, whose software is available open source at divmod.org.

Fuse: a Python replacement for SubEthaEdit (developers' mailing list).

Guido van Robot: a small programming language for teaching basic programming concepts. GvR was written by high school students. Not to be confused with Guido van Rossum (also GvR), the inventor of Python.

MoinMoin: a wiki wiki engine.

Nevow: a web application framework, successor to Twisted Woven.

Plone: a content management system (CMS) for Zope.

Python: the last programming language you'll have to learn.

Twisted: an asynchronous framework for all types of Internet applications.

Zope: a Web application universe, the Emacs of Web applications.

Python UK (April 16-17; Oxford, England)

EuroPython (June 7-9; Göteborg, Sweden)

OSCON (July 26-30; Portland, Oregon, USA)

Northwest Python Sprint (date TBD; Seattle, Washington, USA)