PyCon DC 2004

Showing off new software, planning for the future and running sprints in DC.

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.

The Zen of Python

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.

Sprints

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.

Trending Topics

Upcoming Webinar

Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report

August 27, 2015
12:00 PM CDT

DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.