An Interview with Guido van Rossum

The Features and Futures of the Python Programming Language

Willison:

Would you say that a lot of the interesting work and excitement that's going on now in Python, or more of it at least than in the past, is on the application side? That is, applications of Python rather than new features of Python?

van Rossum:

Yes. My own perception of that is somewhat colored by where people ask my advice, which is still, of course, about changes to Python internals or at least standard libraries. But I see an enormous amount of stuff going on where people are just developing very exciting applications. I think Zope is probably the prime example at the moment.

Willison:

These next items aren't exactly applications, but two areas where there's a lot of interest and activity with Python now are JPython and Python on Win32. I wondered if you had a sense of how much Python activity is now happening on platforms other than, say, Unix platforms?

Related Reading Python Programming On Win32 Help for Windows Programmers By Mark Hammond, Andy Robinson

van Rossum:

Well, I think, a lot. The Windows platform especially gets a lot of attention. It also gets attention from some very specialized people. I think you're also working with Mark Hammond.

Willison:

Yes. We have a book that's going into production, which means it's about three months away from being published. By Mark Hammond and Andy Robinson, called Python Programming on Win32.

I don't know what's going on with JPython lately. Is there development happening there?

van Rossum:

Well, there is some development. I think Barry [Warsaw, the current development leader] is still waiting to release the final 1.1 of JPython. He's released a number of betas, and I think he is really very close to finishing it up. The big hit we suffered there, of course, was Jim Huginin [the original developer of Jpython] leaving CNRI [Guido's employer and a major sponsor of Python development].

Willison:

Yes, that was a dirty trick on Jim's part.

van Rossum:

Well, he's really very busy with his new job as far as I can tell.

Willison:

He's an intense guy. I'm sure he couldn't do a job without giving his all to it.

It seems that Python has some very natural advantages on both the Win32 platform and the Java platform because of its object orientation and its ability to abstract things. Is that accurate?

van Rossum:

Yes, I definitely believe that it has some good cross-platform properties. Object orientation was one of the techniques I used to make Python platform independent. I think the real key to Python's platform independence is that it was conceived right from the start as only very loosely tied to Unix. In fact, early development was done on the Macintosh, and one of the early target platforms was Amoeba [a distributed OS], which was very unlike Unix. And that, combined with my almost instinctual desire for portable software, which comes from way back in the early '80s, made me focus on making sure that Python ran on multiple platforms in a different way than some of the other scripting languages that started out as Unix only. Some of them said, "We're never going to be bothered by porting it to other platforms." Then when people find out that it is actually possible to do a sort of port, users are crying for it. Python was naturally ported to Windows and has attracted some attention there.

Willison:

I think I was trying to ask a slightly different question, which was: it seems to me that there's a great need for a language that makes Java less complicated. Some think JavaScript is that language, but lately interest in JavaScript as a Java scripting language seems to be dropping off. But in addition to being multi-platform, Python is a very natural scripting language for Java. It fits the kind of development that Java also fits. Do you agree?

van Rossum:

Absolutely. If you're talking about Java in particular, Python is about the best fit you can get amongst all the other languages. Yet the funny thing is, from a language point of view, JavaScript has a lot in common with Python, but it is sort of a restricted subset. The real disadvantage that JavaScript has at the moment is that it is so confined to its original target platform, inside browsers. It needn't be confined there, actually, but that's where it ended up. All the development in JavaScript is focused on that environment, so that's sort of a self-fulfilling prophecy. This doesn't help Java at all, because even though Java was promoted early on as something that would run in the browser, the real application areas for Java are in many different places, like Jini and servlets. In those places, JavaScript is not very useful.

JavaScript the language doesn't preclude supporting Jini and servlets, but unless an implementation provides that support, there is very little there. Also, JavaScript cut out the language features like classes and inheritance that JPython offers.

Willison:

It also seems that Microsoft is implementing object models as the way scripting languages or any language can interact with Microsoft applications also fits conceptually with Python packages and so forth.

van Rossum:

Mark Hammond is working in this area, with Windows Scripting Host. It is definitely an area where Python fits almost perfectly. That's quite independent from Java, actually.

Willison:

It just seems that the way that both the Java developers and the Windows developers are thinking is very similar to the way that Python understands programming, and that seems like an interesting area for future development.

van Rossum:

Well, Python takes programming seriously. Python takes programming as seriously as C or Java or C++. My own use of Python is as a real programming language and not as a tool to write quick, throwaway scripts. For the most part, anyway.

In my daily work, I work on very large, complex, distributed systems built out of many Python modules and packages. The focus is very similar to what you find, for example, in Java and, in general, in systems programming languages. That is very different from the sort of the typical application domain you find for languages like Tcl or Perl.

Willison:

Now, we have gotten a lot of book proposals lately about new scripting languages that are always described as elegant... powerful and elegant, in fact. That combination always makes me think of combining Arnold Schwarzenegger with Fred Astaire. Pike is an example.

van Rossum:

Yes. Lua too, I suppose.

Willison:

Yes. Something called MEL . And something called Squeak, which is being created at Disney.

van Rossum:

Isn't Squeak a Smalltalk derivative?

Willison:

Yes. It's used in movie production and 3D graphics, as is MEL. It seems like there's an explosion of small, single-purpose languages.

But I wondered, are there advantages to such little languages or is a person better with a more general, fairly serious programming scripting language like Python?

van Rossum:

Well, it's interesting that you mention movie production, because Industrial Light & Magic have basically standardized on Python for much of the same work that MEL or Squeak are being used for. So there's definitely room for general scripting languages in that area as well.

I would guess that the decision to create a small special purpose language or use an existing general purpose language is one of the toughest decisions that anyone facing the need for a new language must make. There are lots of advantages to both.

Related Reading Learning Python By Mark Lutz, David Ascher

If you decide to design your own language, there are thousands of sort of amateur language designer pitfalls. You think you don't need all the advanced features. You think, "Well, maybe our variable names only need to be single letters because we don't expect variables to be used very often." Maybe you put a dollar sign in front of a variable so you can use regular words as string literals without quotes.

Maybe you think, "Okay, we're going to implement simpleminded functions, but they're only going to be one line. Just a single expression." You think, "Maybe we'll implement arrays, but we're going to place some restrictions on the implementation and thus on the semantics of the arrays because we don't want to spend all the time implementing that." Or maybe you say, "Okay, well, we don't need arrays at all."

So your version 1.0 of your little language has very simple implementation and it has a sort of a matching simple semantics and simple syntax. Invariably, you'll find that if the language is any good, your users are going to take it to places where you never thought it would be taken.

So your version 2.0 adds new features. And as you approach the maturity of your little language, it ends up being not so little at all. There was a project at Lawrence Livermore National Labs where many years ago they went down this path for scripting and controlling very large numerical calculations. There were some very generic pieces of software that had lots of configurability, and they needed some kind of script to drive those big applications, to direct them to the right data sets, and to control the number of iterations.

They ended up gradually over the years inventing an incredibly baroque scripting language, and then they stumbled on Python and decided to scrap their internal language and switch to Python. (Because of backward compatibility, scrapping the internal language is still going on.)

Willison:

I have one final question. What would you be interested in letting people know about the Computer Programming for Everybody project? How is that going, and what should people know about it?

van Rossum:

Well, let me see. We're in the final stages of negotiating the actual contract with DARPA, that will give us a little bit of money for, say, the first half of next year and possibly some this year.

At the same time, there is a new version of the proposal that extends over five years. We're asking for more money. We're cooperating with various locations like the Alice Group at CMU, the University of Chicago, and some local schools. We are planning to attract a bunch of high schools to test-drive this program.

We want to create a very exciting new Python project, which will come up with two different streams of materials. One stream of materials is educational material. A lot of the questions we get for Python are questions like, "How do I teach Python to a 13-year-old?" or "How do I teach myself programming? I've never written a piece of software before." That is something that even Learning Python with all its qualities doesn't really address because it generally assumes too much programming proficiency already.

Willison:

Right. It assumes that somebody can already program, right?

van Rossum:

Exactly. So, here the challenge is to teach students programming at the same time as teaching them Python. Now, it's my belief that Python is a lot easier than to teach to students programming and teach them C or C++ or Java at the same time because all the details of the languages are so much harder. Other scripting languages really don't work very well there either. With those other languages, you run into all sorts of idiosyncrasies and details.

Willison:

And they all seem to be subsets either of C or Shell programming.

van Rossum:

Yes, or both.

Willison:

And therefore, the concepts that you're teaching are not fully formed concepts.

van Rossum:

That is absolutely correct. Python, with its roots in an educational language and its original decision not to look very much like C or Shell programming, has a much better chance there.

The second stream of material that is going to come out of this project is a programming environment and a set of programming tools where we really want to focus again on the needs of the newbie. This environment is going to have to be extremely user-friendly. On the other hand, we want to make it expert-friendly. And we also want to make it a lot easier to start using it without much computer experience than existing programming environments are.

There's a whole tradition of programming environments, and whether it's Visual Basic or Visual C++ or Java development environments from IBM or other vendors, they all seem to share the property that you start the application and you have about 2,000,000 windows and pop ups and menus and dialogues and choosers, and little output widgets. Now, all those things at some point certainly serve a purpose, but it's so incredibly overwhelming when you first see that kind of environment. It can be even for an expert, if you're not already familiar with the actual environment.

I'm fairly familiar with Visual C++, for example, because I used that for Python development on Windows. And still the Visual Basic environment is just so daunting.

Willison:

I'd say so.

van Rossum:

So we want to make a set of Python-specific tools that eventually may not be completely Python-specific. One of my dreams is that there will be a very fluent connection to JPython and then to Java. But that's really sort of a pipe dream at this point. We are really going to focus on Python.

This environment will eventually have tools that will help you understand the structure of software. I think newbies are going to try to open the box of big applications if they can and peek around and change things. We would like to make that an actual possibility.

My current example is Mozilla. It's open source. You can download the sources to your computer. It takes up several hundred megabytes of disk space, probably twice that when you actually want to compile it.

You can build your own Netscape Navigator. So in theory, there's nothing that stops you from editing the source so that the menu bar disappears, or that moving GIFs are disabled, or whatever feature you would like.

In practice, even very experienced software developers don't find it very easy to make any changes at all to Mozilla because it's such a large body of code. Finding your way around it is such a daunting task. I realize that if the thing were written in Python, it might be ten times smaller and it would still be very large.

I have this hope that there is a better way. Higher-level tools that actually let you see the structure of the software more clearly will be of tremendous value.

Willison:

That does seem really interesting. It also seems that the current Windows programming model, by exposing object models, gives you an interesting way of doing that, at least on the Windows platform. But of course that's without source code. You can see the structure they expose, but that's about it.

van Rossum:

Yes. The Windows model is very much based on hiding the source code. I'm told that there are sometimes very good reasons to hide the source code because sometimes you just do not want your programmers to change an environment. There are also very good reasons that plead for allowing change to the source code. So I think some kind of version control management system integrated with all this will give both parties the right degrees of freedom.

Willison:

That is great information, and I appreciate it. Nice talking to you, Guido.

van Rossum:

Thanks, Frank.

Return to: Frankly Speaking