LJ Interviews Guido van Rossum

Mr. Kuchling talks to the creator of Python to find out about the past, present and future of this versatile programming language.

Guido van Rossum is the author of the
Python interpreted language. I interviewed him at the end of July
to find out what's been happening with Python, and what can be
expected in its future.

The Past

Andrew: What inspired you to
write the Python interpreter?

Guido: One, I was working at
Centrum voor Wiskunde en Informatica (CWI) as a programmer on the
Amoeba distributed operating system, and I was thinking that an
interpreted language would be useful for writing and testing
administration scripts. Second, I had previously worked on the ABC
project, which had developed a programming language intended for
non-technical users. I still had some interesting ideas left over
from ABC and wanted to use them.

I had a two-week Christmas holiday with nothing to do. So, I
wrote the first bits of the Python interpreter on my Mac so that I
didn't have to log into CWI's computers.

Andrew: What other languages
or systems have influenced Python's design?

Guido: There have been many.
ABC was a major influence, of course, since I had been working on
it at CWI. It inspired the use of indentation to delimit blocks,
which are the high-level types and parts of object implementation.
I'd spent a summer at DEC's Systems Research Center, where I was
introduced to Modula-2+; the Modula-3 final report was being
written there at about the same time. What I learned there showed
up in Python's exception handling, modules, and the fact that
methods explicitly contain “self” in their parameter list. String
slicing came from Algol-68 and Icon.

C is a second influence, second only to ABC in importance.
Most of Python's keywords, such as break,
continue and others, are identical to C's, as
are operator priorities. C also affected early extension modules;
many of them, such as the socket and POSIX modules, are simply the
corresponding UNIX C functions translated into Python, with some
modifications to make programming more comfortable. For example,
errors raise exceptions rather than return a negative value, and
sockets are objects.

The Bourne shell was also a model for Python's behaviour.
Like the shell, Python can execute scripts by specifying their file
name, but when run without arguments, it presents you with an
interactive prompt. This is well suited for experimenting with the
language or with a new module you're trying to learn.

The Present

Andrew: What are the most
interesting Python applications you've seen?

Guido: People are doing many
neat things with it. Infoseek uses Python as part of their
Ultraseek search engine; the web crawler portion is written in
Python and can be configured by writing Python code. A group at
Lawrence Livermore National Labs is using Python to control
numerical calculations. Companies such as Digital Creations are
using Python in web-related products.

Andrew: What features of
Python are you most pleased with?

Guido: The feel of the whole
system suits my style of programming well, for obvious reasons. The
ability to run the interpreter interactively and the ability to
write code from the bottom up and test it piecemeal combine to let
me write code quickly. Other people find that it makes them more
productive, too.

Python also connects well to the environment where it's
running. ABC was monolithic, putting its own abstractions on top of
the operating system. For example, ABC had persistent name spaces
that carried the values of variables across successive executions.
These name spaces were implemented as disk files, but there was no
way to read an arbitrary file or to wander around the file system.
I thought that was a serious mistake, so extensibility was
important from the start with Python, and it's not difficult to
write an extension to interface to a new C library.

Andrew and Guido discuss the future of Python

Andrew: How has the user
community surprised you? How did it influence the language's
direction, once it started to be used widely?

Guido: Once the source code
was made available for downloading, it forced me to make the
installation process very easy, just to save myself from answering
the same questions over and over. It also forced me to write better
documentation.

Much of the language still consists of what I like, but users
have always been important in suggesting new things and in
fine-tuning them. Some of the early adopters of the language, such
as Tim Peters and Steve Majewski, focused on very subtle design
details and helped immensely by clarifying the way various features
should work; e.g., they convinced me to support mixed arithmetic.
Much of the current (and still growing) set of Internet-related
modules was contributed or suggested by users.

Andrew: What feature of
Python are you least pleased with?

Guido: Sometimes I've been
too quick in accepting contributions, and later realized that it
was a mistake. One example would be some of the functional
programming features, such as lambda functions.
lambda is a keyword that lets you
create a small anonymous function; built-in functions such as
map,
filter and
reduce run a function over a
sequence type, such as a list.

In practice, it didn't turn out that well. Python has only
two scopes: local and global. This makes writing lambda functions
painful, because you often want to access variables in the scope
where the lambda was defined, but you can't because of the two
scopes. There's a way around this, but it's something of a kludge.
Often it seems much easier in Python just to use a
for loop instead of messing around with lambda
functions. map and friends work
well only when a built-in function that does what you want already
exists.

Andrew:
In your introduction to Mark Lutz's book Programming Python
(O'Reilly, 1996), you mention that your day job involves writing
Python code. What is your job, and how do you use Python in
it?

Guido: I now work at the
Corporation for National Research Initiatives (CNRI) in Reston,
Virginia. CNRI was interested in building a mobile code system
called the Knowbot System, because mobile programs are useful for
many different purposes. For example, let's say you're indexing a
web site. Normally, you'd download all the data using the network
and index it, which uses a lot of bandwidth. Also, you can't detect
whether two documents are identical copies of each other without
downloading them, causing even more wasted time and resources. With
mobile code, you could run the indexing program on the server
sending only the index, which is a relatively small amount of data,
back when the job is done.

CNRI realized that mobile agents would have to be executed in
a restricted environment to prevent them from damaging anything on
the system; therefore, running Knowbot code in an interpreted
language would be required. So, CNRI looked at the languages
available at the time, settled on Python as the overall best
language for the job and hired me to work on the Knowbot
system.

Since then we've actually built the Knowbot system, which
required relatively few changes to Python; most of the pieces for
restricted execution were already in place even before I started at
CNRI. Along the way, CNRI also developed Grail, a web browser
written in Python, and most recently we've developed a
load-balancing system as part of another research effort. Another
application for Knowbots, a subject for future research, is
protection of intellectual property. To prevent people from making
illegal copies of documents purchased in electronic form, the
documents might be embedded inside a Knowbot program that verified
the user was authorized to view them. How to make this work is
still an open question!