The Artima Developer Community
Sponsored Link

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

<<  Page 3 of 4  >>


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.

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.

<<  Page 3 of 4  >>

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use