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!
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide