LJ Interviews Guido van Rossum
Guido van Rossum is the author of the Python interpreted language. I interviewed him at the end of July to find out what's been happening with Python, and what can be expected in its future.
Andrew: What inspired you to write the Python interpreter?
Guido: One, I was working at Centrum voor Wiskunde en Informatica (CWI) as a programmer on the Amoeba distributed operating system, and I was thinking that an interpreted language would be useful for writing and testing administration scripts. Second, I had previously worked on the ABC project, which had developed a programming language intended for non-technical users. I still had some interesting ideas left over from ABC and wanted to use them.
I had a two-week Christmas holiday with nothing to do. So, I wrote the first bits of the Python interpreter on my Mac so that I didn't have to log into CWI's computers.
Andrew: What other languages or systems have influenced Python's design?
Guido: There have been many. ABC was a major influence, of course, since I had been working on it at CWI. It inspired the use of indentation to delimit blocks, which are the high-level types and parts of object implementation. I'd spent a summer at DEC's Systems Research Center, where I was introduced to Modula-2+; the Modula-3 final report was being written there at about the same time. What I learned there showed up in Python's exception handling, modules, and the fact that methods explicitly contain “self” in their parameter list. String slicing came from Algol-68 and Icon.
C is a second influence, second only to ABC in importance. Most of Python's keywords, such as break, continue and others, are identical to C's, as are operator priorities. C also affected early extension modules; many of them, such as the socket and POSIX modules, are simply the corresponding UNIX C functions translated into Python, with some modifications to make programming more comfortable. For example, errors raise exceptions rather than return a negative value, and sockets are objects.
The Bourne shell was also a model for Python's behaviour. Like the shell, Python can execute scripts by specifying their file name, but when run without arguments, it presents you with an interactive prompt. This is well suited for experimenting with the language or with a new module you're trying to learn.
Andrew: What are the most interesting Python applications you've seen?
Guido: People are doing many neat things with it. Infoseek uses Python as part of their Ultraseek search engine; the web crawler portion is written in Python and can be configured by writing Python code. A group at Lawrence Livermore National Labs is using Python to control numerical calculations. Companies such as Digital Creations are using Python in web-related products.
Andrew: What features of Python are you most pleased with?
Guido: The feel of the whole system suits my style of programming well, for obvious reasons. The ability to run the interpreter interactively and the ability to write code from the bottom up and test it piecemeal combine to let me write code quickly. Other people find that it makes them more productive, too.
Python also connects well to the environment where it's running. ABC was monolithic, putting its own abstractions on top of the operating system. For example, ABC had persistent name spaces that carried the values of variables across successive executions. These name spaces were implemented as disk files, but there was no way to read an arbitrary file or to wander around the file system. I thought that was a serious mistake, so extensibility was important from the start with Python, and it's not difficult to write an extension to interface to a new C library.
Andrew: How has the user community surprised you? How did it influence the language's direction, once it started to be used widely?
Guido: Once the source code was made available for downloading, it forced me to make the installation process very easy, just to save myself from answering the same questions over and over. It also forced me to write better documentation.
Much of the language still consists of what I like, but users have always been important in suggesting new things and in fine-tuning them. Some of the early adopters of the language, such as Tim Peters and Steve Majewski, focused on very subtle design details and helped immensely by clarifying the way various features should work; e.g., they convinced me to support mixed arithmetic. Much of the current (and still growing) set of Internet-related modules was contributed or suggested by users.
Andrew: What feature of Python are you least pleased with?
Guido: Sometimes I've been too quick in accepting contributions, and later realized that it was a mistake. One example would be some of the functional programming features, such as lambda functions. lambda is a keyword that lets you create a small anonymous function; built-in functions such as map, filter and reduce run a function over a sequence type, such as a list.
In practice, it didn't turn out that well. Python has only two scopes: local and global. This makes writing lambda functions painful, because you often want to access variables in the scope where the lambda was defined, but you can't because of the two scopes. There's a way around this, but it's something of a kludge. Often it seems much easier in Python just to use a for loop instead of messing around with lambda functions. map and friends work well only when a built-in function that does what you want already exists.
Andrew: In your introduction to Mark Lutz's book Programming Python (O'Reilly, 1996), you mention that your day job involves writing Python code. What is your job, and how do you use Python in it?
Guido: I now work at the Corporation for National Research Initiatives (CNRI) in Reston, Virginia. CNRI was interested in building a mobile code system called the Knowbot System, because mobile programs are useful for many different purposes. For example, let's say you're indexing a web site. Normally, you'd download all the data using the network and index it, which uses a lot of bandwidth. Also, you can't detect whether two documents are identical copies of each other without downloading them, causing even more wasted time and resources. With mobile code, you could run the indexing program on the server sending only the index, which is a relatively small amount of data, back when the job is done.
CNRI realized that mobile agents would have to be executed in a restricted environment to prevent them from damaging anything on the system; therefore, running Knowbot code in an interpreted language would be required. So, CNRI looked at the languages available at the time, settled on Python as the overall best language for the job and hired me to work on the Knowbot system.
Since then we've actually built the Knowbot system, which required relatively few changes to Python; most of the pieces for restricted execution were already in place even before I started at CNRI. Along the way, CNRI also developed Grail, a web browser written in Python, and most recently we've developed a load-balancing system as part of another research effort. Another application for Knowbots, a subject for future research, is protection of intellectual property. To prevent people from making illegal copies of documents purchased in electronic form, the documents might be embedded inside a Knowbot program that verified the user was authorized to view them. How to make this work is still an open question!
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Nice article, thanks for the
16 min 6 sec ago
- I once had a better way I
6 hours 2 min ago
- Not only you I too assumed
6 hours 19 min ago
- another very interesting
8 hours 12 min ago
- Reply to comment | Linux Journal
10 hours 5 min ago
- Reply to comment | Linux Journal
16 hours 59 min ago
- Reply to comment | Linux Journal
17 hours 16 min ago
- Favorite (and easily brute-forced) pw's
19 hours 7 min ago
- Have you tried Boxen? It's a
1 day 59 min ago
- seo services in india
1 day 5 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?