An Interview with Guido van Rossum

Guido van Rossum created the Python language in the early 1990s at CWI in Amsterdam, responding to an inner desire for a more elegant and powerful scripting language. He now leads the PythonLabs development team at Zope Corporation.

Guido will be presenting a session on the State of the Python Union at O'Reilly's upcoming Open Source Convention. He recently took a few minutes out of his busy schedule to answer some questions about Python and open source development.

Stewart: I know you just released version 2.2.1 of Python. What's new in this version?

van Rossum: That can be interpreted in two ways: what's new in 2.2 (since 2.1), or what's new in 2.2.1 (since 2.2).

Many people are still using some version of 2.1; we even released a
bugfix release, 2.1.3, a few days before 2.2.1 was released.
Therefore the first question is an important one. For the answer I
usually refer to Andrew Kuchling's paper by that title. For me personally, the highlights
are (1) iterators and generators, and (2) a new class implementation,
which currently lives besides the old one, but will eventually supplant
it.

What's new in 2.2.1 isn't particularly interesting, and that's as it
should be: it's a maintenance release that adds stability to the new
features introduced in 2.2, as well as fixing a number of rare old
bugs. Anybody who is using 2.2 should upgrade to 2.2.1.

I did manage to sneak in half a new feature, which is a faint echo of
a feature that will be introduced for real in 2.3 -- a new built-in function bool() that takes an arbitrary value as its argument and
returns a canonic True or False value; there are also built-in
constants True and False. The difference with 2.3 is that in 2.3,
bool will be a separate type (a subtype of int); in 2.2, bool()
returns a plain int, which is more compatible, though less useful than
the 2.3 version.

The goal of adding this to 2.2.1 is not so much that
you can start writing code that anticipates the new feature, but that
it allows us to more easily backport code written for 2.3 to 2.2.1.

Stewart: What features are you most excited about that are being developed
for future versions of Python?

van Rossum: As far as the language is concerned, I'm looking forward to the full integration of the new class implementation. This is quite a ways off,
mostly because backwards compatibility is so important in this phase
of Python's life.

Another thing, much farther in the future, is compilation to C or
machine code. I used to think that this was impossible and (perhaps
because of that) uninteresting, but recent experiments (like Armin
Rigo's Psyco and Greg Ewing's Pyrex) suggest that this will eventually
be possible. It should provide Python with an incredible performance
boost and remove many of the reasons why many people are still
reluctant to switch to Python.

I'm also excited about a new version of IDLE that is being developed
as a separate project. IDLE (a Tkinter-based Python
editor and shell) has always been one of my pet projects, but I've had
no time to work on it. Fortunately, several others under the
leadership of Stephen Gava have picked it up where I dropped it, and
are adding many new features.

Perhaps the deepest change to IDLE is separate execution. Currently,
when you type a Python command in IDLE's shell environment, it is
executed in the same process that is running IDLE. While this is very
efficient, and it is normally easy enough to keep IDLE's internal data
separate from the user's code, there are certain things that become
difficult or impossible, like testing a program that has its own
Tkinter main loop (which would interfere with IDLE's main loop), or
process management.

It's also hard to interrupt a runaway piece of
code in the current version. All of these problems will be fixed. There
will also be a proper interactive configuration dialog, and the
interface for testing your program will become much more intuitive.

I know that not everybody takes IDLE seriously. But most decent
alternatives are commercial products, and you did ask me what excites
me.

Stewart: What inspired you to develop Python in the first place? Was there
something you needed that wasn't available in other scripting
languages?

van Rossum: I needed a decent scripting language. Remember, it was over 12 years ago. Tcl hadn't escaped from the labs
in Berkeley yet; an early Perl existed but, besides offending my
language design sensibilities, it was strictly limited to Unix.

I needed something that would run first and foremost on Amoeba, a
distributed operating system developed by Andrew Tanenbaum's group.
The only alternative available on that platform was a port of the Unix
V7 shell; but it was hard to teach it about Amoeba's (at the time)
exciting new features.

I combined this external need with an internal one: the desire to do a
follow-up to the failed ABC language project (still available on the
Web).

I had been part of the ABC development team in the early ‘80s, and
in my head I had analyzed some of the reasons it had failed. Failure
can be measured in many ways. On the one hand, upper management
withdrew all funding from the project; on the other hand, there were
few users. I had some understanding for the reasons for the latter,
and to some extent Python is a direct response to that.

In part, of course, the reason for ABC's failure was that it was too
early for such a high-level language. But I believe that several of
its early major design decisions contributed to its demise:

Unconventional terminology intended to make beginners more comfortable
but instead threw off more experienced users

A monolithic implementation
that made it hard to add new features

Too much emphasis on theoretically optimal performance

Not enough flexibility in its
interaction with other software running on the same computer (ABC
didn't have a way to open a file from within a program)

Python
addresses several of these issues by its object-oriented design and by
making it really easy to write extension modules.

Stewart: What would you most like to change about the Python development
process or community?

van Rossum: I wish I could still interact with the community at large like I used to, but the traffic on comp.lang.python is too overwhelming, so I peek
in rarely nowadays (unless there's a specific topic that has my
interest).

I don't have a personal desire to change anything about the
development process -- it is going as well as it can given the growth
of the community. A friend once said, "In a sufficiently large
population there are no uncontroversial topics," and my recent forays
into comp.lang.python have certainly shown this to be true. But I
think the community is doing a good job of developing mechanisms and
processes where they are needed.

Stewart: Has the Python community coped well with the influx of newbies
attracted by Zope?

van Rossum: I'm not sure that they were all attracted by Zope -- there are lots of
other reasons for less experienced people to want to check out Python.
For example, a growing number of schools and colleges are using Python
in their Introduction to Programming courses.

I think the community is coping well -- I see more experienced
developers showing up too, so that there's more help available for the
beginners. And there are more developers helping out with moving
the language forward.

Stewart: What's your personal style of project leadership?

van Rossum: You'd have to ask the people who work with me to get an honest answer.

I usually don't like to tell people what to do or how to do it. I
prefer to lead more by example. If I have to make a decision, I
usually do it only after gathering plenty of feedback. That doesn't
mean I always follow the recommendations though. If I have a strong
intuition about what's right, and the arguments to the contrary don't
sound convincing, I'll do it my way rather than deferring to
"democracy." But if good new arguments are brought forward later, I
can change my mind.

Another aspect of my leadership style is that I don't like conflict.
Most of the time my attitude is, "Why can't we all get along?" I
guess psychologists would call me a fuser. This may be why it is so
hard for me to accept that there are some people (maybe only two!) in
the community who appear to be bearing a personal grudge to me. I
have to work really hard to rationalize this and accept that I can't
please everyone.

Stewart: What do you think is the most important part of an open source
project?

van Rossum: There's no single important piece, it all needs to fit together. The project must fulfill a need or fit a niche; the project leader must have
decent leadership skills and good technical skills, but also
be able to defer to others with more specialized knowledge; someone
must have a bit of a knack for public relations; and so on. I guess
it's much the same as what makes a successful business.

In the case of Python, I think one technical aspect that it shares
with many other successful open source projects is that the software
has more than one level of extensibility. On the one hand, this
allows end users of different skill levels to adapt the software to
"scratch their own itch."

Beginners write Python modules, advanced
developers can write extensions in C or C++ to make Python do things
that it can't do out of the box, and because it's open source, there's
always the ability to modify the interpreter itself if you really want
to.

The other equally positive side of this coin is that it keeps
the key developers free from having to solve every end user's problem.
I get very few requests to change the language to meet an end user's
needs, and when I do, I can usually explain how they can write an
extension that does what they want without having to change the
language.

Stewart: Do you think there are any lessons from the success of the open
source Python project that could be applied to commercial software
development?

van Rossum: This is an important question, though hard for me to answer. Before my current employer, Zope Corporation, I never worked in a commercial
software shop. I've always worked in an academic setting. Zope
Corporation applies many of the open source lessons, as we use a
distributed, open development process that deeply involves customers
and non-employee developers around the world. We also practice
Extreme Programming a lot.

Our CTO, Jim Fulton, has introduced a very interesting innovation
called a "sprint." A number of programmers, some more experienced,
some less, get together for a few days for an intensive programming
session, typically using pair-programming, Extreme-Programming style.

Sprint participants are both company employees and non-employees
interested in participating in the development of the open source Zope
codebase. At the end of the sprint, we usually have a significant new
piece of working code with unit tests, the less experienced programmers
have learned a lot, and we have a few new contributors to the Zope
project. This process has really reinvigorated the Zope development
process.

Which brings me to another lesson from open source, from my
colleague Tim Peters. Tim says this is so important to him now that
he'll never go back to working for a closed-source company. The
lesson is that an open source development process breeds very loyal
employees.

In a typical closed-source company, programmers often
develop large amounts of code to which they develop personal
attachment. But when projects get canceled, companies are
restructured, and management changes, they often lose access to their
own code, which is de-motivating. Having your source code out there in
the open is a real motivator to have pride in your code and keep
improving it.

Stewart: Are you sick of Monty Python yet?

van Rossum: I almost never watch Monty Python shows, but when I do, I still get a kick out of them. Some of the Pythons' later movies (Meaning of Life, Brazil)
are among my all-time favorites.

Stewart: What gives you the most fun these days?

van Rossum: Playing with my son Orlijn. He's 7 months old now, and is already developing a great personality. He's got a real sense of humor, and
it's fun to watch him make progress in his discovery of the world.

van Rossum: I'm a last-minute kind of guy (you can interpret that as you will), so I can't tell you yet. The many lessons I've learned over the past
year will play an important role, though.

Editor's Note: We actually have some idea. Guido will present a session at OSCON on the State of the Python Union, which will cover the latest Python releases, new technologies, and future Python plans.