PyCon DC 2003
Two talks on documentation formats were presented: reST and Twisted Lore. reST (reStructured Text) is a simple ASCII format for rich text that is on its way to becoming a Python standard. The input is similar to a Wiki format, and the output is (officially) HTML, (unofficially) LaTeX and (experimentally) DocBook.
Lore uses an XHTML variant for input and produces HTML and LaTeX output. XHTML was chosen over LaTeX and DocBook for input because it dramatically lowers the bar for participation: everybody writes documentation in HTML nowadays anyway and making it XML-conformant requires only a few little changes, like always closing your <P> tags and writing <BR> as <BR />. Special <DIV>, <SPAN> and <PRE> classes (pseudo styles) handle footnotes, syntax highlighting of Python source code and so on. Lore adds TOC links at the top for each of your <H1> headers, puts previous/next links on the pages and generates a crude index.html. The LaTeX output format allows conversion to Postscript and PDF. The lore command has a lint option to check the input format, and it even checks the syntax of your embedded Python listings. It also warns if the listings are wider than 80 characters.
The highest quality talk I attended was the threads tutorial. It was well organized and clear, making an often-confusing subject seem simple. Aahz explained the global interpreter lock (GIL) and the threading module and explained why queues are the greatest thing since sliced bread.
There were a couple talks on configuration-file parsers, including Zope's ZConfig, Leonard Richardson's Beyond the Config File framework and my PyYAML open-space session.
Ian Bicking, a Webware developer, led a "Web Framework Shootout". He wrote a paper describing and comparing several of the non-Zope frameworks. In the beginning, remember, there was Zope. But Zope had its discontents, who developed CherryPy, SkunkWeb, Quixote, Webware and others, which are as modular and Pythonic as Zope is monolithic and weird. (Twisted also is modular, but it's more than a mere web application server.) Ian argues that this multiplicity of servers may have solved one problem, but it created another: so many incompatible interfaces inhibit code sharing and content sharing between them. So he pleads, "Don't invent any more web application servers. Instead, improve the ones that exist, and help them consolidate into a few killer apps." Some attendees objected and said the ability to write your own application server easily is one of Python's strengths, and who cares if there are five or five hundred of them.
Another debate revolved around whether the singlethread (Twisted), multithread (Webware, Zope) or multiprocess (SkunkWeb, Apache) model is best. Somebody asked whether any of Python's web application servers have been deployed in situations with over 200 users. This brought a response by somebody who had worked on Yahoo Mail. Yahoo Mail was written in Python at a time when none of the other servers existed. It scaled to several million users with ease, although it was later replaced with C++.
The Zope team continues to be responsive to the requests and complaints of Zope application developers. In my Python9 article, I wrote about how the pleas of Zope programmers for support led the Zope team to beef up the documentation and to encourage the previously-discouraged Python methods (external methods) for complex logic. In Zope 3 (unreleased) they've eliminated implicit acquisition, due to complaints from developers that it's too error prone. Now, if you want to acquire an attribute/method from a runtime container (folder), you must ask for it explicitly. In other changes, Zope 3 uses an XML (.zcml) file for configuration. Some developers also are considering running Zope on Twisted.
Some of the talks I didn't attend covered topics such as unit testing, PyChecker (a lint for Python source files), Jython, managing large project releases, the Semantic Web (RDF), Numarray (an alternative to Numeric Python), a .Net wrapper (Korba) and others.
And now, what everybody has been waiting for--the Great Guido discussing Python's evolution. Downloads of Python at python.org continue to increase with every release since 2.0, although not dramatically. The PSF can accept donations now, so maybe it's time to spend a little money to bootstrap Python marketing.
Guido continued the tradition of summarizing the flame war du jour. He claims to have a knack for punting controversial topics to comp.lang.python to hash out, not realizing which topics are weapons of mass destruction. The ternary operator proposal (akin to C/Perl's ?: operator) turned out to be even more explosive than last year's boolean-type proposal. Two public votes proved inconclusive beyond the fact that 50% of the respondents want a ternary operator and 50% don't. Guido is leaning toward the following syntax if he decides to implement it:
result = if C1: x1 elif C2: x2 else: y
This syntax got slightly more votes in both elections than the other proposals:
result = C ? x : y # Pro: like C/Perl. Con: symbols are unpythonic. result = if C then x else y # Con: expression form has 'then' but statement form doesn't. result = x if c else y # Pro: like list comprehensions. Con: order of expressions is confusing.
Guido then went over Tim Peter's list of 20 "Zen of Python" items: "Beautiful is better than ugly. Explicit is better than implicit. Readability counts. Errors should never pass silently. In the face of ambiguity, refuse the temptation to guess." Two maxims deserve special mention:
"There should be one--and preferably only one--obvious way to do it." This is the most-violated rule because sometimes you come up with a better way later, and sometimes the obvious way is not always obvious. That leads to the following rule.
"...although that way may not be obvious unless you're Dutch." Guido used some obscure reference to Holland's Christian past to explain this. For an example, he said it's obvious (if you're Dutch) that a tuple is not an immutable list. A list is a collection of things that have something in common (whether they are the same type or not). Usually you don't know ahead of time how many there will be. A tuple is a group of unrelated things that want to stay together. Even if Python had immutable lists, it would have tuples too.
Guido proposed one addition to the Zen: "Be kind on Usenet, some posters are only eleven years old."
Where does Guido want to take Python? He wants to reduce feature duplication: the string module, xrange, classic classes, short integers, 8-bit strings (to be replaced by Unicode for strings and by a mutable byte array for binary data), map and filter, lambda, != vs <>. He wants to do some efficiency fixes on the compiler and support native compilation to machine code. The jury is still out on whether interfaces will be added to the language. He'd like to release Python 2.3 on July 4 if possible.
On the last day of the conference, Guido gave a lightning talk titled "Python Regrets". He describes features he wishes he hadn't added to Python. See the PDF slides he made for OSCon 2002 for the complete list. Here are a few highlights:
.__int__() is ambiguous. It's used both for converting to an integer (truncating) and for a user integer object to specify its integer value (non-truncating). These should be separate methods.
myDict.has_key(key) was borrowed from ABC, but key in myDict is better.
Relative imports were a bad idea.
Tabs should not have been allowed for indentation. Or at the very least, mixed tabs and spaces should not have been allowed.
Using backslashes \ for line continuation is ugly. Use extra () or something else instead.
print and myFile.write(text) are too dissimilar. There should be a convenient but consistent way to print to the console.
input() is both dangerous and hard to teach. It's dangerous because wrong input comes in as who knows what type, raises an exception or causes side effects. It's hard to teach because the EOF behavior is different from sys.stdin.readline().
- Integrating Trac, Jenkins and Cobbler—Customizing Linux Operating Systems for Organizational Needs
- Tech Tip: Really Simple HTTP Server with Python
- New Products
- Non-Linux FOSS: Remember Burning ISOs?
- EdgeRouter Lite
- Returning Values from Bash Functions
- RSS Feeds
- Raspberry Pi: the Perfect Home Server