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().
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- I once had a better way I
57 min 43 sec ago
- Not only you I too assumed
1 hour 15 min ago
- another very interesting
3 hours 8 min ago
- Reply to comment | Linux Journal
5 hours 1 min ago
- Reply to comment | Linux Journal
11 hours 55 min ago
- Reply to comment | Linux Journal
12 hours 11 min ago
- Favorite (and easily brute-forced) pw's
14 hours 3 min ago
- Have you tried Boxen? It's a
19 hours 54 min ago
- seo services in india
1 day 26 min ago
- For KDE install kio-mtp
1 day 27 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?