Sponsored Link •
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
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.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.
Come back Monday, January 20 for Part II of this conversation with Python creator Guido van Rossum.
Python.org, the Python Language Website:
Introductory Material on Python:
Python FAQ Wizard:
Guido van Rossum's home page:
Other Guido van Rossum Interviews: