Posted
by
Roblimo
on Friday April 20, 2001 @12:00PM
from the burned-out-on-monty dept.

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.

[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?

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:

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.

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?