Guido van Rossum created the Python language in the early 1990s at CWI in Amsterdam, responding to an inner desire for a more elegant and powerful scripting language. He now leads the PythonLabs development team at Zope Corporation.
Guido will be presenting a session on the State of the Python Union at O'Reilly's upcoming Open Source Convention. He recently took a few minutes out of his busy schedule to answer some questions about Python and open source development.
Stewart: I know you just released version 2.2.1 of Python. What's new in this version?
van Rossum: That can be interpreted in two ways: what's new in 2.2 (since 2.1), or what's new in 2.2.1 (since 2.2).
Many people are still using some version of 2.1; we even released a bugfix release, 2.1.3, a few days before 2.2.1 was released. Therefore the first question is an important one. For the answer I usually refer to Andrew Kuchling's paper by that title. For me personally, the highlights are (1) iterators and generators, and (2) a new class implementation, which currently lives besides the old one, but will eventually supplant it.
What's new in 2.2.1 isn't particularly interesting, and that's as it should be: it's a maintenance release that adds stability to the new features introduced in 2.2, as well as fixing a number of rare old bugs. Anybody who is using 2.2 should upgrade to 2.2.1.
I did manage to sneak in half a new feature, which is a faint echo of
a feature that will be introduced for real in 2.3 -- a new built-in function
bool() that takes an arbitrary value as its argument and
returns a canonic True or False value; there are also built-in
constants True and False. The difference with 2.3 is that in 2.3,
bool will be a separate type (a subtype of
int); in 2.2,
returns a plain
int, which is more compatible, though less useful than
the 2.3 version.
The goal of adding this to 2.2.1 is not so much that you can start writing code that anticipates the new feature, but that it allows us to more easily backport code written for 2.3 to 2.2.1.
Stewart: What features are you most excited about that are being developed for future versions of Python?
van Rossum: As far as the language is concerned, I'm looking forward to the full integration of the new class implementation. This is quite a ways off, mostly because backwards compatibility is so important in this phase of Python's life.
Another thing, much farther in the future, is compilation to C or machine code. I used to think that this was impossible and (perhaps because of that) uninteresting, but recent experiments (like Armin Rigo's Psyco and Greg Ewing's Pyrex) suggest that this will eventually be possible. It should provide Python with an incredible performance boost and remove many of the reasons why many people are still reluctant to switch to Python.
I'm also excited about a new version of IDLE that is being developed as a separate project. IDLE (a Tkinter-based Python editor and shell) has always been one of my pet projects, but I've had no time to work on it. Fortunately, several others under the leadership of Stephen Gava have picked it up where I dropped it, and are adding many new features.
Perhaps the deepest change to IDLE is separate execution. Currently, when you type a Python command in IDLE's shell environment, it is executed in the same process that is running IDLE. While this is very efficient, and it is normally easy enough to keep IDLE's internal data separate from the user's code, there are certain things that become difficult or impossible, like testing a program that has its own Tkinter main loop (which would interfere with IDLE's main loop), or process management.
It's also hard to interrupt a runaway piece of code in the current version. All of these problems will be fixed. There will also be a proper interactive configuration dialog, and the interface for testing your program will become much more intuitive.
I know that not everybody takes IDLE seriously. But most decent alternatives are commercial products, and you did ask me what excites me.
Stewart: What inspired you to develop Python in the first place? Was there something you needed that wasn't available in other scripting languages?
van Rossum: I needed a decent scripting language. Remember, it was over 12 years ago. Tcl hadn't escaped from the labs in Berkeley yet; an early Perl existed but, besides offending my language design sensibilities, it was strictly limited to Unix.
I needed something that would run first and foremost on Amoeba, a distributed operating system developed by Andrew Tanenbaum's group. The only alternative available on that platform was a port of the Unix V7 shell; but it was hard to teach it about Amoeba's (at the time) exciting new features.
I combined this external need with an internal one: the desire to do a follow-up to the failed ABC language project (still available on the Web).
I had been part of the ABC development team in the early ‘80s, and in my head I had analyzed some of the reasons it had failed. Failure can be measured in many ways. On the one hand, upper management withdrew all funding from the project; on the other hand, there were few users. I had some understanding for the reasons for the latter, and to some extent Python is a direct response to that.
In part, of course, the reason for ABC's failure was that it was too early for such a high-level language. But I believe that several of its early major design decisions contributed to its demise:
Python addresses several of these issues by its object-oriented design and by making it really easy to write extension modules.
Stewart: What would you most like to change about the Python development process or community?
van Rossum: I wish I could still interact with the community at large like I used to, but the traffic on comp.lang.python is too overwhelming, so I peek in rarely nowadays (unless there's a specific topic that has my interest).
I don't have a personal desire to change anything about the development process -- it is going as well as it can given the growth of the community. A friend once said, "In a sufficiently large population there are no uncontroversial topics," and my recent forays into comp.lang.python have certainly shown this to be true. But I think the community is doing a good job of developing mechanisms and processes where they are needed.
Stewart: Has the Python community coped well with the influx of newbies
attracted by Zope?
van Rossum: I'm not sure that they were all attracted by Zope -- there are lots of other reasons for less experienced people to want to check out Python. For example, a growing number of schools and colleges are using Python in their Introduction to Programming courses.
I think the community is coping well -- I see more experienced developers showing up too, so that there's more help available for the beginners. And there are more developers helping out with moving the language forward.
Stewart: What's your personal style of project leadership?
van Rossum: You'd have to ask the people who work with me to get an honest answer.
I usually don't like to tell people what to do or how to do it. I prefer to lead more by example. If I have to make a decision, I usually do it only after gathering plenty of feedback. That doesn't mean I always follow the recommendations though. If I have a strong intuition about what's right, and the arguments to the contrary don't sound convincing, I'll do it my way rather than deferring to "democracy." But if good new arguments are brought forward later, I can change my mind.
Another aspect of my leadership style is that I don't like conflict. Most of the time my attitude is, "Why can't we all get along?" I guess psychologists would call me a fuser. This may be why it is so hard for me to accept that there are some people (maybe only two!) in the community who appear to be bearing a personal grudge to me. I have to work really hard to rationalize this and accept that I can't please everyone.
Stewart: What do you think is the most important part of an open source project?
van Rossum: There's no single important piece, it all needs to fit together. The project must fulfill a need or fit a niche; the project leader must have decent leadership skills and good technical skills, but also be able to defer to others with more specialized knowledge; someone must have a bit of a knack for public relations; and so on. I guess it's much the same as what makes a successful business.
In the case of Python, I think one technical aspect that it shares with many other successful open source projects is that the software has more than one level of extensibility. On the one hand, this allows end users of different skill levels to adapt the software to "scratch their own itch."
Beginners write Python modules, advanced developers can write extensions in C or C++ to make Python do things that it can't do out of the box, and because it's open source, there's always the ability to modify the interpreter itself if you really want to.
The other equally positive side of this coin is that it keeps the key developers free from having to solve every end user's problem. I get very few requests to change the language to meet an end user's needs, and when I do, I can usually explain how they can write an extension that does what they want without having to change the language.
Stewart: Do you think there are any lessons from the success of the open source Python project that could be applied to commercial software development?
van Rossum: This is an important question, though hard for me to answer. Before my current employer, Zope Corporation, I never worked in a commercial software shop. I've always worked in an academic setting. Zope Corporation applies many of the open source lessons, as we use a distributed, open development process that deeply involves customers and non-employee developers around the world. We also practice Extreme Programming a lot.
Our CTO, Jim Fulton, has introduced a very interesting innovation called a "sprint." A number of programmers, some more experienced, some less, get together for a few days for an intensive programming session, typically using pair-programming, Extreme-Programming style.
Sprint participants are both company employees and non-employees interested in participating in the development of the open source Zope codebase. At the end of the sprint, we usually have a significant new piece of working code with unit tests, the less experienced programmers have learned a lot, and we have a few new contributors to the Zope project. This process has really reinvigorated the Zope development process.
Which brings me to another lesson from open source, from my colleague Tim Peters. Tim says this is so important to him now that he'll never go back to working for a closed-source company. The lesson is that an open source development process breeds very loyal employees.
In a typical closed-source company, programmers often develop large amounts of code to which they develop personal attachment. But when projects get canceled, companies are restructured, and management changes, they often lose access to their own code, which is de-motivating. Having your source code out there in the open is a real motivator to have pride in your code and keep improving it.
Stewart: Are you sick of Monty Python yet?
van Rossum: I almost never watch Monty Python shows, but when I do, I still get a kick out of them. Some of the Pythons' later movies (Meaning of Life, Brazil) are among my all-time favorites.
Stewart: What gives you the most fun these days?
van Rossum: Playing with my son Orlijn. He's 7 months old now, and is already developing a great personality. He's got a real sense of humor, and it's fun to watch him make progress in his discovery of the world.
Stewart: What will you be talking about at O'Reilly's upcoming Open Source Convention (OSCON)?
van Rossum: I'm a last-minute kind of guy (you can interpret that as you will), so I can't tell you yet. The many lessons I've learned over the past year will play an important role, though.
Editor's Note: We actually have some idea. Guido will present a session at OSCON on the State of the Python Union, which will cover the latest Python releases, new technologies, and future Python plans.
Bruce Stewart is a freelance technology writer and editor.
Return to Python DevCenter.
Copyright © 2017 O'Reilly Media, Inc.