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)

Re:Braces vs Whitespace

Good concerns.

Whitespace _by itself_ doesn't affect Python; only indentation does. The difference is that indentation is something that's done to visible stuff. It's almost impossible to hide an indentation.

It's not completely impossible, though; that's why Python's unofficial rule is: "no tabs, and if you want to use tabs, never put spaces before a tab." This is good human advice anyhow.

So in summary, there's nothing about Python's formatting which is invisible.

Hope that helps.

The post to which you're replying is claiming that tools should conform to the language rather than the language to the tools -- I'm a Python fan, but even I don't buy that. Python IS a tool, as is any language. If you're stuck with vi and Python makes it hard to indent using vi, then either Python, vi, or automatic indentation MUST GO. Personally, I've never had a problem, but to those who have, I completely respect their decision to toss out any of the three, even my favorite one.

Of course, that doesn't mean I have to agree when they start badmouthing Python because they chose to toss it out in their one narrow case.

-Billy

Argh. We need license compatibility.

Guido:

Please take a deep breath and go in for one last go-around with the FSF lawyers. Pretty please?

As far as I could tell, the remaining issues are just "legalese exhaustion" on your part rather than actual conflicting goals. Maybe you could deputize a legalese wrangler to finish negotiations for you, or you could take a month-long break in which you never think a single thought about licenses, and then you go back and finish the negotiations.

This is really important to me, although I am not a GPL fanatic, because if it remains the case that the licenses are (allegedly) incompatible, then there will be lots and lots of people who will refuse to combine GPL code with Python, and that would really suck.

For example, I want to package up my open source application Python, Mojo Nation [mojonation.net] to be included in Debian. This would be a way to reach hundreds of thousands (? maybe fewer. Anyone know how many Debian users there are out there?) of highly clueful users and hackers who would otherwise never install Mojo Nation. The Mojo Nation code source code itself is under the LGPL, and some of the open source libraries that it uses are other under free licenses. Would this cause a legal conflict that would force the debian people to keep it off of their servers? I don't know (since it is LGPL instead of GPL), but I would feel so much better if the Python license were officially GPL compatible.

Regards,

Zooko

Re:Argh. We need license compatibility.

Let me point out that the GPL-compatibility doesn't affect software written in Python, only attempts to embed the Python interpreter inside a GPLed program. For example, there's GPLed software written in Java, even though the most commonly used JVM isn't GPLed. Python's license should be irrelevant to whatever license your Python application uses.

Also, note that the Apache license isn't GPL-compatible, yet that doesn't prevent Debian including Apache. I view this debate as a tempest in a teapot; it may affect people who want to do things like embed Python inside the GIMP, say, but most Python users don't have to care.

Re:Argh. We need license compatibility.

The main problem is that Guido can't really do anything about this. It's the CNRI lawyers talking to the FSF lawyers. He doesn't work for either. Neither is depending on him for anything important to them.

I think he's doing a remarkable job of remaining cool in the middle of a legal firefight he has almost no influence over.

Re:Braces vs Whitespace

The bottom line: my vi editor, and I'm sure someone else's EMACS editor, allow me to match braces with a keystroke. While there may be some way to program EMACS to do the same for white space delimitations, I can't imagine finding a way to do that in vi. Considering which of these is the "standard" Unix editor, that seems like a big flaw.

the GPL is not a contract

License == Contract

Not necessarily. A contract is an agreement where two parties make promises to provide benefits to one another: "If you give me $5, I will give you a hamburger."

By contrast, the GPL is a unilateral grant of permission. I don't have to give the FSF anything in exchange for my freedom to redistribute GNU Emacs -- I just have it.

If I modify Emacs and redistribute the modified version, the GPL places restrictions on how I can redistribute it. But even here, the restrictions are not in the form of a contract. The FSF has given me unilateral permission to publish any Emacs-derivative with a GPL-compatible license. It's like saying "I will give you this hamburger on the condition that you don't put cheese on it."

I don't have to give anything specifically to the FSF in exchange for the right to publish my Emacs derivative. For example, I could give copies to my 10 closest friends (none of whom work for the FSF), and they could all use the program for a month, decide they didn't care for it, and delete it. That would count as "publication" under copyright law, but it's hard to see how, in this circumstance, I am benefiting the FSF by adhering to the GPL. (Well, the FSF gets a benefit in the warm fuzzy ideological sense by having more people use GPLed software, even when those people have no connection to the FSF. But it's not like I'm giving them money.)

And if a 12-year-old girl produces a modified version of Emacs, and publishes it under terms that violate the GPL, the FSF could sue to prevent her from distributing it -- not because she violated a contract with the FSF (since she can't legally be bound by a contract), but because she is distributing the FSF's copyrighted material without permission.

(Disclaimer: IANAL, and there are enough odd nooks and crannies in contract law that I could imagine someone arguing the other way.)
--

GPL is fundamentally broken, sorry.

The GPL includes a warranty disclaimer. A warranty disclaimer is part of contract law. But the GPL is explicitly not a contract, but is instead a set of copyright permissions. So the warranty disclaimer doesn't apply to anyone who doesn't copy code.

The GPL warranty disclaimer can't work.
-russ

Re:Braces vs Whitespace

Whee that was a fun way to learn vim scripting syntaxes. Save the following out to a text file, like ~/pymove.vim and do a :source ~/pymove.vim from within vim. Magically, the ",u", or ",d" keystrokes will move you up and down based on indentation. It could use some work but *I* think it's kindof cool. :^)=

:":source ~/GPL.txt, etc...
:func! Safeup()
:if line('.') != 0
: return line('.') - 1
:else
: return line('.')
:endif
:endfunc
:func! Safedown()
:if line('.') != line('$')
: return line('.') + 1
:else
: return line('.')
:endif
:endfunc
:func! Moveup()
: let new_line = Safeup()
: exec ':' . new_line
: let first_indent = indent( line('.') )
: while indent( line('.') ) == first_indent || indent( line('.') ) > first_indent
: let new_line = Safeup()
: exec ':' . new_line
: endwhile
: return( new_line )
:endfunc
:func! Movedown()
: let new_line = Safedown()
: exec ':' . new_line
: let first_indent = indent( line('.') )
: while indent( line('.') ) == first_indent || indent( line('.') ) > first_indent
: let new_line = Safedown()
: exec ':' . new_line
: endwhile
: return( new_line )
:endfunc
:
:" moves the cursor to position found by 'Movedown()'
:map ,d :exec ':' . Movedown()
:" moves the cursor to position found by 'Moveup()'
:map ,u :exec ':' . Moveup()

--Robert

Hrmph!

Does everybody on slashdot think that the only salient feature of Python is that it doesn't use curly braces?

Get over it!

I am being quite serious. If that modest syntax change is enough to keep you from considering a language, you're doomed as a programmer to linguistic provencialism that will keep you from seeing some really elegant ways to simplify and modularize your code. Ever programmed in Erlang [erlang.org]? Haskell [haskell.org]? Scheme [schemers.org]? Prolog [cmu.edu]? You might end up preferring a more mainstream language after all is said and done, but the experience of seeing the new ways of doing things will certainly make those mainstream programs better.

You'll never get that experience, though, if you get scared by the syntactic differences between those languages and C (which are vast). So do yourself a favor and try to see beyond a language's syntax.

--
-jacob

Whitespace and Python as a Teaching Tool

On Whitespace
I have to underline Guido's side remark about the person who asked about whitespace not having used Python before. When I first encountered Python, I thought the idea of syntactically meaningful whitespace was absurd. Then I realized that I, as a novice with very little understanding of Python, could read some of the most complex code from expert Python coders. No way in hell you can do that with Perl where you have to be an expert in order to read other people's code. This syntactic whitespace remains useful even when you become an expert, especially and expert who has to deal with novices daily.

Unless your code is for you and only you, readability is perhaps the single most important feature of your code.

On Python for Teaching
Guido stated:
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!

In a similar vein, I also use Python as a whiteboard language even though I do most of my programming in Java. Specifically, Python let's you write out valid programming logic that reads like English. The result is that by thinking on the whiteboard in Python and then translating into Java, I end up with sounder programming logic.

The FSF has some good points

And contrary to what Guido says, I don't think they're longwinded or hairsplitting. Excerpts from the referenced email [python.org]:

Conclusion: in order to be "compatible" in the strict sense, we need paragraph 7 to remove the choice of law clause. We would also recommend that paragraph 8 be changed to say that copying, modification or distribution constitutes acceptance of the license, but we don't have to have that change to agree that the license is fully "GPL compatible."

They've given him one requirement to make the license fully GPL-compatible, and IMHO it's very reasonable. Virginia, folks, is a very scary place to license software. If you haven't read up on UCITA, do so [ucita.com].

So we have never allowed a license with a choice-of-law clause to be treated as fully compatible with GPL. Virginia is the worst of all choices, because that state has passed the UCITA law, which adds a whole new range of risks and burdens in the distribution of free software.

Now, CNRI's lawyers might not like that, but their job is to do one thing: cover CNRI's ass. That's well and good, but the GPL has loftier goals: guaranteeing our freedoms.

The bottom line is that the GPL is the most powerful defense that Free software has. Yes, the FSF is inflexible, but they're preparing for the worst-case scenario. We'll thank them later, when the GPL stands up in court.

question: is control controlled by its need to control?
answer: yes

Re:Indentation syntax has its problems too

I may be misunderstanding you, but it looks like you're missing the point.

In a language like C, braces express grouping for the computer, and people arrange their code with indentation to make the grouping obvious to themselves (and other people). The problem with this is that the two are not coupled - the braces and the indentation can conflict, *misleading* people about how the compiler is interpreting the program. The cited example is exactly a case in point:

> if (x == 4)
> x = 10;
> y = 6;
>
> Now how did I know that the writers intent was
>
> if (x == 4) { x = 10; }
> y = 6;
>
> or
>
> if (x == 4) {
> x = 10; y = 6;
> }

As C code, it means one thing according to the whitespace and another thing according to the braces - so the programmers intent is undecidable from the context. Even the programmer themselves, rereading code, may be unable to reconstruct the reasoning. If the example is python code, there is no room for doubt. This is a good thing!

Most python programmers i know who came to python with substantial experience had a moment of doubt about the whitespace structuring, and then (sooner or later) an epiphany that not only _can_ it work, it works well. Very well. It's no small bonus that it reduces clutter/visual noise, besides.