Guido van Rossum Unleashed

Here you go - answers to your questions for Guido van Rossum about Python, its future, licensing hassles with the Free Software Foundation, and other neat stuff. Thanks, Guido!

Ruby
by Luke
Thoughts on Ruby?

Guido:
I just looked it up -- I've never used it. Like Parrot, it looks like a mixture of Python and Perl to me. That was fun as an April Fool's joke, but doesn't tickle my language sensibilities the right way.

That said, I'm sure it's cool. I hear it's very popular in Japan. I'm not worried.

Data Structures Library
by GrEp
I love python for making quick hacks, but the one thing that I haven't seen is a comprehensive data structures library. Is their one in development that you would like to comment about or point us to?

Guido:
One of Python's qualities is that you don't need a large data structures library. Rather than providing the equivalent of a 256-part wrench set, with a data type highly tuned for each different use, Python has a few super-tools that can be used efficiently almost everywhere, and without much training in tool selection. Sure, for the trained professional it may be a pain not to have singly- and doubly-linked lists, binary trees, and so on, but for most folks, dicts and lists just about cover it, and even inexperienced programmers rarely make the wrong choice between those two.

Since this is of course a simplification, I expect that we will gradually migrate towards a richer set of data types. For example, there's a proposal for a set type (initially to be added as a module, later as a built-in type) floating. See http://lists.sourceforge.net/lists/listinfo/python-sets and http://python.sourceforge.net/peps/pep-0218.html.

[j | c]Python
by seanw
How do you see the relationship between jPython (the java implementation) and standard cPython (the original C language version) evolving? And do you see the advantages of either one (i.e. portability vs. speed) becoming especially pronounced in light of the recent trend toward distributed software (ala the MS .NET initiative)?

Guido:
Note that the new name is Jython, by the way. Check out www.jython.org -- they're already working on a 2.1 compatible release.

We used to work really close -- originally, when JPytnon was developed at CNRI by Jim Hugunin, Jim & I would have long discussions about how to implement the correct language semantics in Java. When Barry Warsaw took over, it was pretty much the same. Now that it's Finn Bock and Samuele Pedroni in Europe, we don't have the convenience of a shared whiteboard any more, but they are on the Python developers mailing list and we both aim to make it possible for Jython to be as close to Python in language semantics as possible. For example, one of my reasons against adding Scheme-style continuations to the language (this has seriously been proposed by the Stackless folks) is that it can't be implemented in a JVM. I find the existence of Jython very useful because it reminds me to think in terms of more abstract language semantics, not just implementation details.

IMO the portability of C Python is better than that of Jython, by the way. True, you have to compile C Python for each architecture, but there are fewer platforms without a C compiler than platforms without a decent JVM.

Jython is mostly useful for people who have already chosen the Java platform (or who have no choice because of company policy or simply what the competition does). In that world, it is the scripting and extension language of choice.

does Python need a CPAN?
by po_boy
One of the reasons I still write some things in PERL is because I know that I can find and install about a zillion modules quickly and easily through the CPAN repository and CPAN module. I'm pretty sure that if Python had something similar, like the Vaults of Parnassus but more evolved that I would abandon PERL almost entirely.

Do you see things in a similar way? If so, why has Python not evolved something similar or better, and what can I do to help it along in this realm?

Guido:
It's coming! Check out the action in the catalog-sig http://python.org/sigs/catalog-sig/. You can help by joining.

One reason why it hasn't happened already is that first we needed to have a good package installation story. With the widespread adoption of distutils, this is taken care of, and I foresee a bright future for the catalog activities.

Favourite Python sketch?
by abischof
Considering that you named the language after the comedy troupe, what's your favourite Monty Python sketch? Personally, my favourite is the lecture on sheep aircraft, but I suppose that's a discussion for another time ;).

Guido:
I'm a bit tired of them actually. I guess I've been overexposed. :-)

Conflict with GPL
by MAXOMENOS
The Free Software foundation mentions the license that comes with Python versions 1.6b1 and later as being incompatible with the GPL. In particular they have this to say about it:

This is a free software license but is incompatible with the GNU GPL. The primary incompatibility is that this Python license is governed by the laws of the "State" of Virginia in the USA, and the GPL does not permit this.

So, my question is a two parter:

1.What was your motivation for saying that Python's license is governed by the laws of Virginia?

2.Is it possible that a future Python license could be GPL-compatible again?

Guido:
Let me answer the second part first. I asked the FSF to make a clear statement about the GPL compatibility of the Python 2.1, and their lawyer gave me a very longwinded hairsplitting answer that said neither yes nor no. You can read for yourself at http://www.python.org/2.1/fsf.html. I find this is very disappointing; I had thought that with the 1.6.1 release we had most of this behind us, but apparently they change their position at each step in the negotiations.

I don't personally care any more whether Python will ever be GPL-compatible -- I'm just trying to do the FSF a favor because they like to use Python. With all the grief they're giving me, I wonder why I should be bothered any more.

As for the second part: most of you should probably skip right to the next question -- this answer is full of legal technicalities. I've spent waaaaaaaaay to much time talking and listening to lawyers in the past year! :-(

Anyway. The Python 1.6 license was written by CNRI, my employer until May 2000, where I did a lot of work on Python. (Before that, of course, I worked at CWI in Amsterdam, whom I have to thank for making my early work on Python possible.) CNRI own the rights to Python versions 1.3 through 1.6, so they have every right to pick the license.

CNRI's lawyers designed the license with two goals in mind:(1) maximal protection of CNRI, (2) open source. (If (2) hadn't been a prerequisite for my employment at CNRI, they would have preferred not to release Python at all. :-)

Almost every feature of the license works towards protecting CNRI against possible lawsuits from disappointed Python users (as if there would be any :-), and the state of Virginia clause is no exception. CNRI's lawyers believe that sections 4 and 5 of the license (the all caps warnings disclaiming all warranties) only provide adequate protection against lawsuits when a specific state is mentioned whose laws and courts honor general disclaimers. There are some states where consumer protection laws make general disclaimers illegal, so without the state of Virginia clause, they fear that CNRI could still be sued in such a state. (Being a consumer myself, I'm generally in favor of such consumer protection laws, but for open source software that is downloadable for free, I agree with CNRI that without a general disclaimer the author of the software is at risk. I'm happy that Maryland, for example, is considering to pass a law that makes a special exception for open source software here.)

Python 1.6.1, the second "contractual obligation release" (1.6 was the first), was released especially to change CNRI's license in a way that resolved all but one of the GPL incompatibilities in the 1.6 license. I'm not going to explain what those incompatibilities were, or how they were resolved. Just look for yourself by following the "accept license" link at http://www.python.org/1.6.1/. The relevant changes are all in section 7 of the license, which now contains several excruciating sentences crafted to disable certain other clauses of the license under certain conditions involving the GPL. Read it and weep.

The remaining incompatibility, according to the FSF, is the "click-to-accept" feature of the license. This is another feature to protect CNRI -- their lawyers believe that this is necessary to make the license a binding agreement between the user and CNRI. The FSF is dead against this, and their current position is that because the GPL does not require such an "acceptance ceremony" (their words), any license that does is incompatible with the GPL. It's like the old story of the irresistible force meeting the immovable object: CNRI's lawyers have carefully read the GPL and claim that CNRI's license is fully compatible with the GPL, so you can take your pick as to which lawyer you believe.

Anyway, I removed the acceptance ceremony from the 2.1 license, in the hope that this would satisfy the FSF. Unfortunately, the FSF's response to the 2.1 license (see above) seems to suggest that they have changed their position once again, and are now requesting other changes in the license. I'm very, very tired of this, so on to the next question!

Structured Design.
by Xerithane
First off, as a disclaimer I have never actually written anything in Python. But, I have read up on virtually all the introduction articles and tutorials so I have a grasp on syntax and structure.

I have been doing C development for 9 years now, and I know a plethora of other languages including shell scripting, perl, PHP (for scripts). Now, each language uses 'normal' grouping for control structures (if, for, etc).

What was the logic behind creating a whitespace-based syntax rule? And why do you feel it is good, please refrain from the readability answer because that is all I get from those people I know who know Python.

I find, because of my background, it is much easier to read code that uses braces ({}) than whitespace because my mind automatically looks for them. After maintaining legacy code that extends a life span of 20 years from it's first line of code, I have some concerns about the longevity of any Python code. So, my second question is, how well do you see Python holding up for 20 years and why do you think it will hold up that long?

Guido:
What's wrong with the legibility answer? I think that's an *excellent* reason! Don't care if your code is legible?

Don't you hate code that's not properly indented? Making it part of the syntax guarantees that all code is properly indented!

When you use braces, there are several different styles of brace placement (e.g. whether the open brace sits on the same line as the "if" or on the next, and if on the next, whether it is indented or not; ditto for the close brace). If you're used to code written in one style, it can be difficult to read code written in another. Most people, when skimming code, look for the indentation anyway. This leads to sometimes easily overlooked bugs like this one:

  if (x  10)
      x = 10;
      y = 0;

Still not convinced? In 1974, Don Knuth predicted that indentation would eventually become a viable means of structuring code, once program units were small enough. (Full quotation: http://www.amk.ca/quotations/python-quotes/page-1.html)

Still not convinced? You admit that you haven't tried it yet. Almost everybody who tries it gets used to it very quickly and end up loving the indentation feature, even those who hated it at first. There's still hope for you!

So, no, I'm not worried about Python holding out 20 more years.

What is *your* idea of Python and its future?
by Scarblac
There are a lot of "golden Python rules" or whatever you would call them, like "explicit is better than implicit", "there should be only one way to do it", that sort of thing. As far as I know, those are from old posts to the mailing list, often by Tim Peters, and they've become The Law afterwards. In the great tradition of Usenet advocacy, people who suggest things that go against these rules are criticized. But looking at Python, I see a lot more pragmatism, not rigid rules. What do you think of those "golden rules" as they're written down?

What's your idea of the future of Python? Since the PEP process, a lot of new feature ideas have been put forward, and a lot of people feel uncomfortable with quick change to a good language (Python 2.1 is again excellent though, congrats). Do you think or hope Python will be finished one day? If not, isn't the alternative an endless string of added features? "Python 3000" was an idea of a sort of ideal Python that would be worked on, but as I understand Python will now evolve more gradually.

Guido:
You're referring to the "Zen of Python", by Tim Peters: http://www.python.org/doc/Humor.html#zen

It's no coincidence that these rules are posted on the Python Humor page!

Those rules are useful when they work, but several of the rules warn against zealous application (e.g. "practicality beats purity" and and "now is better than never").

While we put "There's only one way to do it" on a T-shirt, mostly to poke fun at Larry Wall's TMTOWTDI, the actual Python Zen rule reads: "There should be one-- and preferably only one -- obvious way to do it." That has several nuances!

Regarding the future, I doubt that any piece of software ever stops evolving until it dies. It's like your brain: you never stop learning. Good software has the ability to evolve built in from the start, and evolves in a way that keeps the complexity manageable.

Python started out pretty well equipped for evolution: it was extensible at two levels (C extension modules and Python modules) that didn't require changing the language itself. We've occasionally added features to support evolution better, e.g. package namespaces make it possible to have a much large number of modules in the library, and distutils makes it easier to add third party packages.

I hear the complaints from the community about the rate of change in Python, and I'm going to be careful not to change the language too fast. The next batch of changes may well be aimed at *reducing* complexity. For example, there are PEPs proposing a simplification of Python's numeric system (like eradicating the distinction between 32/64-bit ints and bignums), and I've started to think seriously about removing the distinction between types and classes -- another simplification of the language's semantics.

Strangest use of Python
by Salamander
What use of Python have you found that surprised you the most, that gave you the strongest "I can't believe they did that" reaction?

Guido:
I find few things strange.

For the most obfuscated code I've ever come across, see the Mandelbrot set as a lambda, http://www.python.org/doc/FAQ.html#4.15.

Digital Creations has written a high-performance fully transactional replicated object database in Python. That's definitely *way* beyond what I thought Python would be good for when I started.

Some people at national physics labs like LANL and LLNL have a version of Python running on parallel supercomputers with many hundreds of processors. That's pretty awesome.

But my *favorite* use of Python is at a teaching language, to teach the principles of programming, without fuss. Think about it -- it's the next generation!

--Guido van Rossum (home page: www.python.org/~guido)