Here's a summary of PyCon I wrote up for work. I'll probably submit it to Linux Gazette next month, but you get to read it first. :)
-- Mike Orr <[email protected]>Title: PyCon2010
PyCon 2010 conference summary
The annual Python conference was held February 19-21 in Atlanta, at the Hyatt Regency downtown. Attendance was 1100+, which was significantly higher than previously. "PyCon has become a place to showcase the talent in the Python community," said Steve Holden, the leader of the Python Software Foundation (but not the conference chairman anymore). As such, there will be "more Steve, less Guido". This will be shown when we get into the keynotes below. The logistics all ran smoothly: good schedule flow, signage, talk flow, registration flow, means, and open space. The main problem was WiFi in the main session rooms, which gets overwhelmed every year no matter how many routers you throw at it. So the unlucky ones had to get Internet access in the smaller rooms or in the evening.
The organizers add new things to the schedule every year in a continuing experiment to see what works best. Instead of three keynotes, there were two this year, plus short summaries of the state of each Python implementation. The keynote speakers were Mark Shuttleworth and Antonio Rodriguez.
Mark Shuttleworth
Mark Shuttleworth is a philanthropist and the founder of the Ubuntu Linux distribution, and is a fan of PyPy. His goal as a philanthropist is to "accelerate development in the entire open-source community". Running a distribution gives him contact with all kinds of software, because Ubuntu has to coordinate with the developers of all the packages in the distribution. Mark has three recommendations for software project leaders: cadence, quality, and design.
"Cadence" means regular releases every N months. Ubuntu has 6-month releases, and a 2-year cycle for major changes. For a regular application, Mark recommends a 3-month or 6-month interval because it fits evenly into a year. (Web applications may be different because they can have a continuous upgrade process: there's nothing for the user to install.) Most open-source projects do not do regular releases but instead follow the "release it when it's done" philosophy. The advantage of regular releases is it brings a wave of users, testers, and publicity at every release. It also forces developers to break down their grand vision into "What can we do this cycle?" and "What can we do next cycle?", which helps prevent stagnation. Ubuntu is willing to take brand-new versions from projects that do regular releases, because they are more likely to be reliable than brand-new versions of irregularly-released products.
Re quality Shuttleworth says, "If you make quality a serious priority, you'll attract developers who are interested in quality." He stresses the importance of a good version control system with branching and merging, and an automated test suite. Keep the main line of development in the trunk, and let developers keep their own unfinished code in branches. Nothing goes in the trunk unless it passes the tests. That way, anybody can install trunk anytime and have a working program. This means more ordinary users are willing to run trunk, which means you have more beta testers and a greater reputation for reliability. He also recommends developers review each others' code. He says this is a good task for newbie developers with a general knowledge of the language: they can spot mundane errors and also learn the project's coding style.
Re design he says, "We need to make room in our communities for design professionals." People who specialize in user interfaces and the users' needs rather than in code wizardry. The open-source mentality of "it's good enough for developers to use" has to stop because it has negative consequences for users far removed from them. He recommends the age-old test of, "Sit on your hands and keep silent as you watch a user try to use your software." They don't need your help when you're in the room; they need it long before when you decide what to commit to the trunk.
Antonio Rodriguez
Antonio has been in software engineering and management since 1996, in HP and startups. He has happily been using Python since 2001. His management style is to get everybody in the company to learn to program, including marketers and interns. Everybody has access to the trunk, and is encouraged to install whatever they wish. More scary, everybody has commit privileges and can push to production. As a corollary, let everybody review each other's commits. Antonio makes two observations: "These non-programmers are already programming... in Excel!" and "98% of American companies have 10 employees or fewer. That means there are enough people for many new companies at PyCon." (140 new companies, to be exact.)
This "have programmers teach programming to everybody" is part of a larger philosophy. He also thinks marketers should teach marketing to everybody. Everyone should learn to do everything. Those who just want to hardcore code can at least make their programs modular so that other people can work on parts of them.
Antonio calls Python the best representation of a high dynamic range language. But he sees three main challenges: combat FUD, add more batteries, and fix the packaging situation.
Re combating FUD, users are confused about all the anti Python 3 posts in project forums. All projects should commit to moving to Python 3, even if they won't be ready to do it until next year. This gives users reassurance about the project's long-term direction, and about the future of Python 3.
Re batteries, put more widespread, mature packages into the standard library, such as BeautifulSoup and httplib2. Keep some focus on the web because that's the emerging OS.
Re packaging, there are too many distribution formats. DEB, RPM, distutils, setuptools, pip, distribute, O my! "This is heading toward CLASSPATH hell." Python needs a standard packaging system, maybe distribute. ( Public service announcement.)
Antonio says the python.org homepage is "better than it was, but still pre Web 2.0." He recommends thinking about the main message (three little points), and gearing the home page to communicate these.
Python implementations
Each Python implementation got 15 minutes to outline its current status. There are now five implementations:
- CPython, the standard version
- Unladen Swallow, Google's JIT compiler for CPython
- IronPython for .NET
- Jython for Java
- PyPy, or Python written in Python
(Pynie, or Python 3 on Parrot, did not get a plenary talk but did get a regular talk.)
Guido was so not into giving keynotes anymore. Representing CPython, he took questions from IRC, which was visualized via Twitter on the plenary screen. Since the questions and answers were one-liners, I'll keep them in that format:
- Packaging software is a pain because it's all about platforms you didn't know existed and don't have the hardware for.
- "The complete freedom of Ruby syntax sort of gives me the creeps."
- "Once it's in the standard library, it's dead." In other words, evolving packages are better off as third-party packages so they aren't tied to Python's 2-3 year release cycle.
- The email package is broken in Python 3.
- "Django or TurboGears? Definitely Django. Sorry TurboGears folks." (This was the most controversial statement of the conference.)
- How many roads must a pony trot down, before you can call him a horse?" Some audience members shouted, "42!" (This is a Django in-joke, and of course a nod to Douglas Adams.)
- "What can we do to address global warming? Ride your bikes more."
Unladen Swallow has just been accepted into the Python core, so it will be in Python 3.2 in December. Unladen Swallow is Google's just-in-time compiler for Python, which makes most programs run significantly faster. One single optimization sped up Django by 20%. It can also run Twisted, Zope, bzr, Mercurial, etc. There are plenty of other speed improvements outlined, but not enough developers to implement them. They hope that by putting it into the Python source tree, it will encourage more developers to work on it. No compiler experience is necessary -- being a Python user gives you knowledge of Python's corner cases, which is what's needed to make sure Unladen Swallow behaves properly.
Jython is at version 2.5.1 for Python 2.5. Version 2.6 is expected by the end of the summer, then 3.2 for Python 3. Jython runs most pure Python packages now including Django, Pylons, SQLAlchemy, distribute, pip, etc.
The talks and everything else
Besides the keynotes there were regular talks, invited speakers, lightning talks, open space, vendor booths, and a new thing called a poster session. A poster session is like a visual talk. Some twenty posters were arranged like an art gallery, with the "speaker" standing next to each one. The attendees milled about the room, looking at posters and asking questions of the "speaker".
I attended educational talks on adapters, eventlets (which are like coroutines), upcoming Unittest features, a new metadata standard for distutils, and a tour through the Repoze packages (libraries spun off from Zope). A DJ showed how to mix audio content in Python. Another talk discussed how to write books using our software-development tools, and how to get publishers to accept formats other than Word. I also incidentally discovered a nifty command-line parsing library, argparse, which will replace optparse in Python 3.
The talk repertoire was unusually strong this year due to the recruitment of more talk reviewers. Several talks I couldn't attend because they were simultaneous with other talks I was at. So I'll have to wait for the videos to see how Python is modeling battlefield scenarios in the military, get the scoop on the global interpreter lock (GIL), see Mercurial's internals, see how diversity makes better outcomes, learn about Pynie and actor-based programming, and see a continuous integration (continuous testing) system.
My main interest is web frameworks and Pylons, so we had an open space session on the state of the frameworks and the WSGI protocol. All of the main WSGI frameworks (Pylons, TurboGears, and Repoze.BFG) have slowed down their feature changes and are concentrating on code cleanup and optimization. This shows they've turned a corner in their evolution. We discussed how to make needed changes to the WSGI spec, which has been stalled for a year. We decided we can't wait any longer for consensus, so we're just going to write our own spec for WSGI 1.1 and 2.0, which the Python PEP editors can either accept or reject, but we're going to use it anyway. We also discussed the common codebase for the next versions of Pylons, TurboGears, and BFG, which is called Marco. After that, we pretty much worked on our own in the sprints without further meetings, because we were each doing widely different things. I worked on the WebHelpers documentation.
Next year's conference will be in Atlanta again in March. Attendance will be capped at 1500 due to the venue's capacity. The 2012 conference will likely be in the Bay Area.
