Human Factors

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.

Breaking Code Release to Release

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.