A Conversation with Guido van Rossum, Part II

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 six 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 Part I: The Making of Python, Van Rossum describes Python's history, major influences, and design goals.
• In this installment, Van Rossum talks about Python's original design goals—how he originally intended Python to "bridge the gap between the shell and C," and how it eventually became used on large scale applications.

Python's Original Design Goals

Bill Venners: What were your original design goals for Python? I had always imagined you wanted to create an easy-to-learn language. You wanted to maximize developer productivity by creating an easy-to-read, easy-to-write language. But from your description of Python's history (see Part I), it sounds like you were trying to fix things that frustrated you in ABC, a language that was designed to make it easy for intelligent non-programmers to learn.

Guido van Rossum: Actually, my initial goal for Python was to serve as a second language for people who were C or C++ programmers, but who had work where writing a C program was just not effective.

Bill Venners: Not effective why?

Guido van Rossum: Because maybe it was something you'd do only once. It was the sort of thing you'd prefer to write a shell script for, but when you got into the writing details, you found that the shell was not the ideal language—you needed more data structures, more namespaces, or maybe more performance. The first sound bite I had for Python was, "Bridge the gap between the shell and C."

So I never intended Python to be the primary language for programmers, although it has become the primary language for many Python users. It was intended to be a second language for people who were already experienced programmers, as some of the early design choices reflect. On the other hand, intuitively I probably stuck to many of ABC's design principles. Because although I had my criticisms of ABC, I borrowed many of its valuable elements, which eventually made Python a great language for people who aren't ace programmers or who are just learning. We now have a large community of people using Python as an educational language, teaching Python in schools. These people aren't and may never be professional programmers, but they still find some programming skills useful.

Did Scaling Up Surprise You?

Bill Venners: I have used Python as a scripting language, but I have met people who use it for more. For example, Bruce Eckel uses it as his main language.

Guido van Rossum: Zope Corporation, where I work, uses it as the main development language. All Zope software is written in Python.

Bill Venners: To manage mailing lists on my server I use Mailman, which is also written in Python.

Guido van Rossum: Yes, Mailman is pure Python.

Bill Venners: And Mailman is not a script. I would call it an application or a system.

Guido van Rossum: Absolutely.

Bill Venners: You said initially you intended Python to be a bridge between the shell and C. Did it surprise you that people would also use it to build apps and systems? Did something change over time?

Guido van Rossum: I can't say it surprised me because it happened so gradually. I thought we'd write small Python programs, maybe 10 lines, maybe 50, maybe 500 lines—that would be a big one. We figured we'd provide library modules that implement bits of functionality that kept being needed again and again. For example, one thing we added fairly early on was a low-level module implemented in C that gave you full access to sockets. We were lucky in a sense that the same socket API was also available on Windows as WinSock. So immediately we had platform-independent socket primitives. The socket primitives were pretty low level. They weren't quite as low level as in C, because we got away from the notion of a file descriptor as a small integer, and instead said, a socket is an object and it has a bunch of methods. All the methods correspond one to one to the system calls that operate on sockets, and the arguments are usually just strings representing some data, or occasionally a tuple of a host name and a port number.

In addition, the Internet was developing and growing more popular—this was the early 1990s. New protocols were being invented and HTTP arrived. It was easy to write implementations of all these protocols as pure Python modules by just using the socket module, as we did in C. Similar things happened in other areas, for example, with numeric Python. Numeric Python is also a core of C code that implements efficient numerical array operations, as well as links to existing numerical libraries. On top of that, it lets you write fairly serious numerical operations.

Python and Large Applications

Bill Venners: Have you seen problems with Python scaling up to apps the size of Zope? Is there a limit? You said originally you thought 500 lines would be a big Python program.

Guido van Rossum: That was just my lack of imagination. The only thing we had to add to the language, at some point, was a new structuring mechanism on top of modules. The number of modules started proliferating and every user started creating large numbers of their own modules, and it was clear that there would be namespace conflicts. So we said we'd make it easy to group modules together in a package. And again, it uses similar syntax to Java, although the way it works and the details of the syntax are slightly different. However, it gives you the same hierarchical namespace of modules inside subpackages inside packages; you can go as deep or as shallow as you want. That's really the only thing we did to support writing larger programs.

Before I joined Zope, the people there implemented a few data structures that they needed in C, which is a legitimate use of making extensions to Python in C. They implemented the persistency mechanism with a transactional object database and all that wonderful stuff on top of some C code, and all the implementation details were then done in Python. They also introduced—I think as a means to support writing larger programs—the concept of interfaces, which is not entirely different from Java interfaces. Although they were done as a user add-on, the syntax is not ideal, but the functionality is complete. You can say this class implements this interface, or groups of interfaces. You can then test instances of that class to see if they really do conform to the protocol defined by the interface. You can define interfaces. Your interfaces can inherit from each other to structure your interfaces.

Usefulness of Privates

Bill Venners: Could you describe what the debate was about regarding the usefulness of privates in Python?

Guido van Rossum: The addition of privates was another small language change that was meant to make writing large programs easier. To me, it's mostly useful to address people's irrational fears than act as a practical tool. There are situations where privates are very useful, because you know you have your own namespace. But in many cases, I think it is overused.

People who fear that someone will call their code with the wrong arguments, and who are used to having static-typed language prevent that at the compiler level, will try to prevent that happening in their code by adding explicit assertions. People will check the types. They'll think, "Oh, this only works for strings, so now I'll assert that the input argument is a string."

That is the completely wrong approach, because someone could easily implement something that works just as well with your code and behaves sufficiently like a string. Maybe it's a proxy for a string, which behaves in almost every aspect as a string, except that its type is a proxy. That's something we use in Zope a lot. The persistency mechanism uses proxies, as does the security mechanism that executes untrusted Web- submitted code. Untrusted code is executed in a sandbox environment using proxies for objects that the code shouldn't be accessing directly. So the fact that the language doesn't enforce types at either the compiler level or the implementation level is actually helpful.

Next Week

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

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? Readers have already posted 1 comment about this article. Why not add yours?

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.