LJ Interviews Guido van Rossum

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.

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.

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!

Andrew: What ongoing Python-related developments do you find most exciting?

Guido: We're working on a Python consortium that would fund future development of Python, but there's nothing to report at this time (late July 1998). It's very exciting to see Python find its way into ever more new products and projects. If I had to name one really big exciting thing, it would be JPython.

Andrew: What exactly is JPython, and what is it suited for?

Guido: The original Python interpreter is written in C. JPython is a completely new implementation of Python written in Java. It brings to Java much of the same advantages that CPython has for a C environment—the interactivity, the high-level language, the ability to glue components together. It can also compile Python programs into Java byte code, which can then be used by other Java code, run as an applet or whatever.

Jim Hugunin has done an excellent job of writing JPython, and it integrates with Java very well. In CPython, to use a new C library you need to write an extension module for it. While there are tools which help with this task, such as David Beazley's SWIG, it still takes some work. Java has the Reflection API, which is an interface for getting information about classes, functions and their arguments. JPython uses the Reflection API to automatically generate an interface, so it can call any Java class without effort.

Andrew: Can you say something about any new features planned for future versions of the interpreter?

Guido: Unicode support is becoming important, and JPython already uses Unicode for its string type, so something will have to be done about that for CPython. The Tk interface could be improved in various ways—speed optimizations, mostly. I'm also thinking about adding Numeric Python's array type to the core language; that presents a few issues, because NumPy's arrays don't behave quite like standard Python lists in various ways, and it might be confusing. Another topic of interest is removing the distinction between classes implemented in Python and extension types implemented as C modules. JPython has a better model for this than CPython does, so those improvements may propagate back into CPython from JPython.

Several proposals have been made for interesting features that would be quite incompatible with the current interpreter, so I'm not sure what should be done about them. For example, one suggestion is static typing; a given variable could be declared to be an integer or a string. That ability would let us catch more errors at compile time, and would let JPython produce a better translation to Java byte codes. We're still thinking about how to implement that one.

Andrew: What things would you like to see for Python?

Guido: Better database access modules, an integrated development environment, more documentation and more users, of course!