The Artima Developer Community
Sponsored Link

The Making of Python
A Conversation with Guido van Rossum, Part I
by Bill Venners
January 13, 2003





ABC's Influence on Python

Bill Venners: Could you give a brief history of Python?


ABC's design had a very clear, sharp focus. ABC was intended to be a programming language that could be taught to intelligent computer users who were not computer programmers or software developers in any sense. During the late 1970s, ABC's main designers taught traditional programming languages to such an audience. Their students included various scientists—from physicists to social scientists to linguists—who needed help using their very large computers. Although intelligent people in their own right, these students were surprised at certain limitations, restrictions, and arbitrary rules that programming languages had traditionally set out. Based on this user feedback, ABC's designers tried to develop a different language.

Another source of frustration for ABC's designers was Basic. At the time, Basic was a fairly crippled language. Although in a sense Basic was aimed at the same audience, non-programmers using computers, it came from a different language design perspective. The Basic versions available at the time were horrible. Almost any interesting Basic program was full of low-level hacks, where one had to poke memory byte 714 to change the screen background color to yellow.

Bill Venners: I remember doing that. When were you working on ABC?

Guido van Rossum: ABC's authors started designing the language in the late 70s and early 80s. I joined the team in 1983. I think we worked until 1986 or 1987. For various reasons, the ABC project wasn't a big success. Maybe it was too early, before there was an Internet to do efficient distribution.

Python Is Born

Guido van Rossum: In 1986 I moved to a different project at CWI, the Amoeba project. Amoeba was a distributed operating system. By the late 1980s we found we needed a scripting language. I had a large degree of freedom on that project to start my own mini project within the scope of what we were doing. I remembered all my experience and some of my frustration with ABC. I decided to try to design a simple scripting language that possessed some of ABC's better properties, but without its problems.


I took ABC's ingredients and shuffled them around a bit. Python was similar to ABC in many ways, but there were also differences. Python's lists, dictionaries, basic statements and use of indentation differed from what ABC had. ABC used uppercase for keywords. I never got comfortable with the uppercase, neither reading nor typing it, so in Python keywords were lowercase.

I think my most innovative contribution to Python's success was making it easy to extend. That also came out of my frustration with ABC. ABC was a very monolithic design. There was a language design team, and they were God. They designed every language detail and there was no way to add to it. You could write your own programs, but you couldn't easily add low-level stuff.

For example, one of the big frustrations for software developers using big mainframe computers in the 60s, 70s, and 80s was input/output (IO). All those IO systems were way too complicated. The ABC designers realized their users' confusion with IO, and decided to do something different. But I think they went overboard.

Instead of IO, where you could read a file and write a file, ABC's designers decided to just have global variables in the program. Their users already understood the concept of global variables. So ABC's designers made those global variables persistent. If you quit your session, all your global variables were saved by the system to a disk file. When you started another session, all your global variables were restored. It worked fairly well, to an extent. It is similar to the idea of a workspace, for example, in Smalltalk. There was a print statement that wrote to the screen, and an input statement that read from a keyboard, but there was no way to redirect IO to or from a file. They literally didn't have any other IO available.

Around that same time, personal computers became available. Personal computers had all this wonderful packaged software that dealt in files. There was a spreadsheet file, a word processor file, a graphics editor file. The ABC users wanted to write little ABC programs that took something from their word processor file and pushed it back into the spreadsheet, or the other way around, but they couldn't because of the limitation on IO.

Bill Venners: They wanted to massage files.

Guido van Rossum: They wanted to massage data, and the data just happened to be in files. It made things difficult that the language didn't have files as a concept.

Extensibility in Python

Guido van Rossum: What made the lack of file support in the ABC language worse was that it wasn't easy to extend ABC. You couldn't say, "This language is implemented in C, so let's just add another function to the standard library that does open a file." ABC had no concept of a standard library. It had built-in commands, but the parser knew about them. It had built-in functions that were very much integrated in the runtime. Adding to the language's standard functionality was very difficult.

For Python, I felt extensibility was obviously a great thing to have. I already knew we would want to use Python on different platforms. I knew we wanted to use Python on Amoeba, the operating system we were developing, and on UNIX, the operating system we were using on our desktops. I knew we would also want to support Windows and Macintosh. I realized that each of those systems had certain functionality that was consistent everywhere, like the standard IO library in C—but there was also different functionality. If you wanted to draw bits on the screen on a Windows system, you had to use different code and a different programming model than you would on a Macintosh or on Unix.

I came up with a flexible extensibility model for Python. I said: "We'll provide a bunch of built-in object types, such as dictionaries, lists, the various kinds of numbers, and strings, to the language. But we'll also make it easy for third-party programmers to add their own object types to the system."

ABC also didn't have namespaces, because it was intended as a relatively small scale language. It only had functions and procedures. You couldn't group them together. Later they added a namespace mechanism, but I thought it was fairly clumsy. By then I had some experience with Modula-2 and Modula-3, so I decided the module would be one of Python's major programming units.

I decided Python would have two different kinds of modules: You can write modules in Python, but you can also write a module entirely in C code. And such a module can make new types and new objects available. That turned out to be a successful idea, because immediately my CWI colleagues, the users, and I started writing our own extension modules. The extension modules let you do all sorts of things: communicate with graphics libraries, data flow libraries, and all sorts of file formats.

Bill Venners: So if I write a module in C, I can use it from my Python program and the types look just like Python types?

Guido van Rossum: That's right. In Python, the way to use a module is always through import statements. Python's import works slightly different from Java's import, but it has the same idea behind it. You import some module name, and the system uses several different ways to locate that module. There's a search path. It looks for files of different types. If you're looking for import foo, it will eventually find either a file or (or foo.dll on Windows). is a piece of Python source code. The Python source is parsed and interpreted. That makes functions and/or classes available to the program., or foo.dll, is a piece of precompiled machine code. It is usually implemented in C or C++, but some people use Fortran to write their extensions that will link to large Fortran libraries. The way you use a precompiled machine code module is, from the Python point of view, exactly the same. You import it. You can list the module's contents to see what's inside. Or, if you're already familiar with the module, you can just start using it.

Next Week

Come back Monday, January 20 for Part II of this conversation with Python creator Guido van Rossum.

Talk Back!

Have an opinion about Python, the ABC language, indentation-based statement grouping, or extensibility? Discuss this article in the News & Ideas Forum topic, The Making of Python

Resources, the Python Language Website:

Introductory Material on Python:

Python Tutorial:

Python FAQ Wizard:

Guido van Rossum's home page:

Other Guido van Rossum Interviews:


Sponsored Links
