Sponsored Link •
Bill Venners: Many Python enthusiasts have told me that when they need to do something in Python, they often find an easy-to-use library and develop that something in three lines of code. The Python language itself seems very human- friendly to me. When you designed the "human interface" of Python, to what extent were you guided merely by taste or your own design sense? To what extent did you do user testing or some kind of research?
Guido van Rossum: The designers of the ABC language, Python's primary influence, tweaked the language based on the feedback from user testing. I've done minimal user testing, but I've been very open to feedback from the user community.
I'm an email junky. I've received many emails from both experienced and beginning Python users. Their suggestions register in my brain, and at some point, manifest into a better design decision.
It's hard to formalize and say these are my design guidelines for the language or for APIs. I have a lot of experience as a programmer. I've been programming since I was 18 years old, in many different environments. I started in a batch shop on a large mainframe, worked my way through Unix time-sharing machines, through PCs and desktops. And I've worked on very different kinds of projects, from research to more application development.
Bill Venners: You have a lot of experience that guides you in design decisions.
Guido van Rossum: Nothing beats experience.
Bill Venners: But it does sound like you're open to community feedback, which also helps you design better.
Guido van Rossum: The Python community does user testing by letting a vast group work with either a prototype implementation, a previous implementation, or a third-party implementation being prepared to go into the standard library. Then we tweak it as we go. We are not afraid to do a whole system redesign. One benefit of the ease with which you can change code in Python is that you're not so afraid to rethink your decisions.
Bill Venners: Sometimes after you've made a public release you might want to make an improvement to something in an API, but programmers have already written code to that API. To what extent do you break code from release to release in Python?
Guido van Rossum: We actually try very hard not to break code unless absolutely necessary. Only under rare circumstances do we resort to fixing a design bug in an incompatible way. More recently, as Python's user community has grown, we've become even more conservative about breaking code.
In the early days I changed the syntax drastically every few weeks or months. That's no longer the case. We now keep the old way of doing things, and add a new, better option that we attempt to persuade people to use. We use the carrot instead of the stick. Maybe eventually we'll start warning people when they run code the old way; for example, when people still use the old regular expression library five years after we said that's no longer how we're going to do it, we're going to give them warnings.