artima - The Making of Python

artima.com/articles/the-making-of-python

The Making of Python

A Conversation with Guido van Rossum, Part I

by Bill Venners

January 13, 2003

Summary

Python creator Guido van Rossum talks with Bill Venners about Python's history, the
influence of the ABC language, and Python's original design goals.
Guido van Rossum is the author of Python, an interpreted, interactive object-oriented
programming language. In the late 1980s, Van Rossum began work on Python at the
National Research Institute for Mathematics and Computer Science in the Netherlands, or
Centrum voor Wiskunde en Informatica (CWI) as it is known in Dutch. Since then, Python
has become very popular among developers, who are attracted to its clean syntax and
reputation for productivity.

In this interview, which is being published in weekly installments, Van Rossum gives
insights into Python's design goals, the source of Python programmer productivity, the
implications of weak typing, and more. In this first installment, Van Rossum describes
Python's history, major influences, and design goals.

Bill Venners: How would you describe Python to developers who have never used it?

Guido van Rossum: From one perspective you can say Python is a very high-level
scripting language. From another perspective you can say it's a high-level programming
language that happens to be implemented in a way that emphasizes interactivity. Python
shares some characteristics with scripting languages, but also shares some
characteristics with more traditional programming languages.

ABC's Influence on Python

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

Guido van Rossum: In the early 1980s, I worked as an implementer on a team building
a language called ABC at Centrum voor Wiskunde en Informatica (CWI). I don't know
how well people know ABC's influence on Python. I try to mention ABC's influence
because I'm indebted to everything I learned during that project and to the people who
worked on it.

1/5
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.

So I started typing. I created a simple virtual machine, a simple parser, and a simple
runtime. I made my own version of the various ABC parts that I liked. I created a basic
syntax, used indentation for statement grouping instead of curly braces or begin-end
blocks, and developed a small number of powerful data types: a hash table (or dictionary,
as we call it), a list, strings, and numbers.

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.

2/5
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

3/5
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 foo.py or foo.so
(or foo.dll on Windows). foo.py is a piece of Python source code. The Python source is
parsed and interpreted. That makes functions and/or classes available to the program.
foo.so, 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.

Resources

4/5
Python.org, the Python Language Website:
http://www.python.org/

Introductory Material on Python:

http://www.python.org/doc/Intros.html

Python Tutorial:
http://www.python.org/doc/current/tut/tut.html

Python FAQ Wizard:

http://www.python.org/cgi-bin/faqw.py

Guido van Rossum's home page:

http://www.python.org/~guido/

Other Guido van Rossum Interviews:

http://www.python.org/~guido/interviews.html

Talk back!

Have an opinion? Be the first to post a comment about this article.

About the author

Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima.com. He is

author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the
Java platform's architecture and internals. His popular columns in JavaWorld magazine
covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini
Community since its inception. He led the Jini Community's ServiceUI project that
produced the ServiceUI API. The ServiceUI became the de facto standard way to
associate user interfaces to Jini services, and was the first Jini community standard
approved via the Jini Decision Process. Bill also serves as an elected member of the Jini
Community's initial Technical Oversight Committee (TOC), and in this role helped to
define the governance process for the community. He currently devotes most of his
energy to building Artima.com into an ever more useful resource for developers.

5/5