How do you feel about the title bestowed on you by the Python community: Benevolent Dictator for Life (BDFL)?

It totally matches the whimsical outlook I try to maintain on Python. By the way, the original title (as I have recently rediscovered after digging through age-old email), invented in 1995, was First Interim Benevolent Dictator For Life. At a meeting of Python developers and fans in Reston, Virginia, everyone present was bestowed with a jocular title, but mine was the only one that stuck.

Do you agree with the following statement taken from Wikipedia: "Python can also be used as an extension language for existing modules and applications that need a programmable interface. This design, of a small core language with a large standard library and an easily-extensible interpreter, was intended by Van Rossum from the very start, due to his frustrations with ABC, which espoused the opposite mindset"?

Yeah, that nails it. ABC was designed as a diamond -- perfect from the start, but impossible to change. I realized that this had accidentally closed off many possible uses, such as interacting directly with the operating system: ABC's authors had a very low opinion of operating systems, and wanted to shield their users completely from all their many bizarre features (such as losing data when you removed a floppy disk at the wrong time). I didn't have this same fear: after all, Python originated in an operating systems research group! So instead I built extensibility into the language from the get-go.

Do you believe that the large standard library is one of Python's greatest strengths?

Despite the misgivings about the quality of (parts of) the standard library that I expressed above, yes, very much so. It has often been a convincing argument for deciding to use Python in a particular project when there were already standard library modules or packages to perform important tasks of the project at hand. Of course, the many third party extensions also add to this argument, but often it helps to notice that a single install (or, on modern Unix systems, no install at all, since Python comes pre-installed) is all what's needed to get started.

Given that you launched the Computer Programming for Everybody (CP4E) initiative while working at the Corporation for National Research Initiatives (CNRI), and the clean syntax of Python, do you think that computer programming is an area that should be more accessible to the general public?

I certainly believe that educators would be wise to teach more about computer use than how to write PowerPoint presentations and HTML (useful though those are). Some people have been quite successful using Python for all kinds of educational purposes, at many different levels. However education is an incredibly politicized subject and I've burned myself enough that I will refrain from further commentary on this subject.

How have Python Enhancement Proposals (PEPs) helped in the development of Python? Which is your favourite?

PEPs have made a huge difference. Before we started using PEPs, the was no specific process for getting something about the language or standard library changed: we had heated debates on the mailing list, but no clear way to make a decision, and no policy about what kinds of changes would need what kind of consensus. Sometimes people "got lucky" by sending me a patch, and if I happened to like it, it went in-- even though perhaps it wasn't always a well-thought-out design.

Other times good ideas got stuck in endless "bikeshedding" (as it has now become known) about itty-bitty details. The PEP process helped frame these debates: the goal of a discussion was to arrive at a PEP, and a PEP needed to have a motivation, a specification, a discussion of alternatives considered and rejected, and so on. The PEP process (with slight variations) was also adopted by other open source projects. I'm sure this has helped generations of open source developers be more productive in their design discussions, and by having the whole PEP process written out (in PEP number 1) it also has served as education for new developers.

My favorite is PEP 666, which was written with the explicit objective to be rejected: it proposes a draconian attitude towards indentation, and its immediate rejection once and for all settled an argument that kept coming up (between tab-lovers and tab-haters). It is a great example of the rule that negative results are useful too.

Do you have any idea how many Python Enhancement Proposals (PEP's) have been submitted over the language's history?

Yes, 239. While they aren't numbered consecutively, they are all kept under version control (at the same Subversion server we use for the Python source tree) so they are easy to count. The highest-numbered one is 3141. This isn't counting a number of proposals that were nipped in the bud -- occasionally someone drafts a PEP but before they can submit it for review it's already killed by the online discussion.

How has 3.01b been received since it's release in June this year? Does it vary greatly from the 3.01a release?

It's been received well -- people are definitely downloading the successive betas (two so far with a third planned) and kicking the tyres. Perhaps the most visible difference from the last of the alphas is the standard library reorganization -- that project hadn't really gotten started until the first beta. Other than that the differences are mostly minor improvements and bugfixes, nothing spectacular.