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?

Ruby isn't really cross between Perl and Python - sure it has elements of both and it is designed to be easy to move from Perl to Ruby. Actually, Ruby borrows heavily from Smalltalk but gives it a more 'familiar' syntax. Everything is an object in Ruby including literals, so you can actually say something like:
"this string".length
and it returns 11.
Or you can make a loop such as:
4.times { |i|
puts i
}

and it prints:
1
2
3
4

To iterate through a hash in Ruby, you do:

someHash.each { |key,value|
#do stuff with key and value
}

That's an example of using a Ruby iterator, one of the nicer language features.

I can think of other code formatting tools (like something that would turn
tabs into 8 spaces) that might case problems if you had some lines with tabs
and some with spaces (whcih I see all the time when a lot of people work on a
file with different tools).

Actually, Python does an excellent job of
figuring out how many spaces you intend a tab to be. I say this from the point
of view of someone who switched from emacs to vim about a year ago, and made
some corresponding changes in code style and tab-versus-space usage (no longer
doing things the way the emacs mode I was using insisted on). I can still edit my old python files
-- and if they look right in the editor, they run correctly in the interpreter
every time, mixed code or no.

Thus, however delicate the whitespace-dependancy system may
appear in theory, it's wonderfully robust in practice.

As for having systems
which let you format things the way you want... one of the nice things about
Python is that it enforces a system which is readable by everyone. There's no
more messing with reformatters or debating code styles -- there's one obvious
style, And It Is Good. Frankly, I like that.

I've been writing python for the last few years, and I've never once had a bug due to whitespace issues.

Not even once.

I've in that time switched from emacs to vim (and, simultaniously, from 4-character to 8-character tabs). I am right now in the process of rennovating a program I wrote back in emacs with the 4-character tabs, and I've more than once used an 8-char tab in a program written in an utterly different style. Not only have I not gotten any bizarre error messages, I haven't gotten any error messages at all.

I don't know what editor or settings you're using, but you're using it (them?) wrong.

And, btw, the emacs python mode *is* clever. When I think about switching back to emacs, it's my number one motivation (I'll probably do it after emacs 22 is out -- isn't that the version slated for color syntax highlighting at the console?)

And MUMPS ignores it, since it is syntactically irrelevent-- there's no real scoping in MUMPS, so there's not even a hit for context switching.

The bugs occur when editing code, when adding an outer loop and the code isn't properly re-formatted. Visually, it is harder to deal with a "running context" (that is, the leading white space means "include me in the previous block") instead of an SOB/EOB-marker context ("everything between the braces is a block").

In communication, a statement is assumed to be related to the previous statement. In fact, we have a special phrase for statements that *don't* relate to the previous statement-- a "non-sequitor." When communicating, we have special markers for "start of topic," and "end-of-topic." Each sentence does *not* start with a marker that says, "I'm part of the same topic as the previous sentence."

As long as your program chunks are short and to-the-point, whitespace blocking is okay. But not everything lends itself to short program blocks.

But, I do have one quibble, the same quibble I've had with Python from the outset. Using whitespace blocking to mandate code structure forces the programmer to the language, and not the other way around. I like my code to fit my style.

I program in MUMPS, a terse database/language written in the late sixties. It's a decent language, as far as that goes, but it also uses whitespace for blocking. I have seen more bugs due to stray spaces than misplaced braces (in C, Perl, etc). Plus, it makes it a pain in the ass when re-formatting huge blocks of code.

Plus, it really *doesn't* make the code more readable. It merely forces the program to a particular style. And Mr. van Rossum's style is not mine. (Arguably, he does have better style than me.)

The problem isn't Python, it's vi. We all know Emacs is hands-down the superior editor (no, the superior GUI environment -- no, the superior OS). And Emacs matches whitespace in Python code. (It prints a message Closes 'if something:' when you close the block... and probably 20 other ways of dealing with blocks that I don't know the keycodes for).

The GPL is a license which defines the terms and conditions of a contract under which you can use the copyrighted material. If you don't accept the terms of the license, and you use the IP covered by the license, then you need to be able to produce some other contract which gives defines the terms under which you get (or more likely get to use) the IP. This is no different from any of those shrink wrap licenses you get with commercial software. When you get commercial software, you aren't actually getting anything more than a license which allows you to do certain things with the code. To follow your analogy, they aren't giveing you the hamburger, just the right to smell the hamburger under certain restrictions. If the GPL can't be enforced, then at the VERY least all of those licenses that you have to accept to get freely available (but proprietary) code are invalid (this covers Java, tons of MS software, most of Stroud's CWS apps, etc.), let alone software sold for $.

Yes, the license is still the same. However, it's not a valid contract, and you need a contract to disclaim warranty.

Following your logic, if I steal some software from someone, they can't disclaim warranty, because there was no contract, and therefore I can sue them for damages the software does.

The GPL can be declined. Indeed, you are not accepting the GPL unless you use the source code or a binary derived from the source code. That is plenty to establish a contract.

I agree the jurisdiction thing is problematic. I assume that FSF's lawyers figured it was the only way to do it. It's amazing that the hardest thing in the world to do legally is give something away without any liability.

You are confusing the license with the packaging. If I stuck the GPL license inside a shrink-wrap package of software (in which case I presume it would be indistinguishable from your typical commercial software license in terms of the reject/accept argument), the license is still the same.

Your case about laws requiring that you have a chance to review the license are a good point, and are a good case for a more cautious approach towards free software distribution that ensures clear presentation of the license in advance of software use. The existing practice of having a LICENSE file and headers at the top of the source code, while pragmatic, is subject to the bizarre variations in contract law. Still, this is talking about the delivery mechanism as opposed to the license.

Just for humor I thought I'd point out that if you really believe that in the real world (as opposed to the legal one) you can reject the terms on a shrink wrap license after reading it, you obviously haven't tried. Unless the license cost you thousands of dollars, it isn't worth the fight.

I agree that the waiver issue is a problem. Contract or no, if you don't establish a jurisdiction for this kind of license fighting it in court is going to be increadibly complex.

No common text editor has a decent "go to the end of the block" function. They all have "go to the matching brace", though.

What happens when you have a line with 8 spaces followed by a line with a tab? I haven't used python, but one language I used that used whitespace indentation treated them differently, so you had lines that looked like they were indented the same, but the interpreter didn't think they were. Add in complications with people who have set their tab stops differently from you, and you might as well give up right now.

It's not the responsibility of a language to conform to the features offered by existing editors

Maybe not in your dream world, but out here in the real world I have code to write, and it there is no editor that will skip to the end of a block in Python, but there is in every other language that I use, then I know what I'm going to choose.

If Joe Schmoe puts in 8 spaces, followed by a tab, it's not Python's fault.

Once again, the real world isn't that simple. Code gets lots and lots of different programmers working on it, over the course of years. And in every other language I use, tabs versus spaces are not an issue. So once again, I look at what has really happened in my 20 years of professional programming experience rather than what should happen in an idea world, see that it would cause major problems in Python, and decide not to choose Python for my next project.

I do a lot of sharing, and have for a long time in several languages. I've never spent much time correcting tabs, but I don't get these problems. In particular, I've never seen anything as bad as what you're saying -- the worst I get is seeing 8-space tabs when the file was formatted for 4-space.

The standard solution in Python is to NEVER use tabs. It's also possible to get away with never using spaces in front of tabs; if you make a mistake that way, you'll see it immediately, and Python will produce an error.

If you DO wind up with spaces in front of your tabs, get rid of your editor -- it's not worth the hassle. Then run Python with the tabnanny option (I think that's -t or -tt) to show you where the mistakes are.

But again, I've never had any of this happen to me. I've never talked to any Python users who have. Python coders just don't ALLOW their code to get so sloppy, any more than C users would allow their code to contain misspelled function names. Why? Because the resulting code wouldn't compile.

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.

The issues with the license are very minor, as you say. Why does the FSF obsess over it so much?

The FSF obsesses over these things because that is the way that the law works. Writing legal documents is a lot like writing complex C memory management code. One off by one error and the entire application segfaults. It's the same thing with the law. One minor detail could cost the case, and when you are talking about something as important to the FSF as the continued "freeness" of the software they have developed you can see why this would make them a little paranoid. Because of this the FSF has worked very hard to make sure that everything that they do is as legal and aboveboard as possible.

That's why they require pen and ink signatures on a legal document assigning them as copyright holder before you can work on GNU software. They know that only the legal copyright holder can press charges in the US, and they want to be sure that they have the power to enforce their license.

Many of the other open source projects (like Python, for instance) have been much more haphazard about the licensing of their product. Guido, for example, failed to make sure before continuing work on Python that it would continue under the same X style license as it always had. His employer got nervous, and their lawyers came up with a license that isn't GPL compatible (at least according to the FSF lawyers).

It is convenient to blame the FSF lawyers, but they didn't change the original Python license. They just pointed out that they don't feel that the new license is GPL compatible. If these details weren't important, then perhaps the people who changed the original license should change it back. The fact of the matter is that the details probably are important enough that neither side is going to bend. The FSF doesn't want to threaten the GPL, and the lawyers at CNRI and Digital Creations don't want to be liable for problems someone might have with Python.

The FSF should be commended for taking care of these details before it starts developing software. If Guido would have done the same, there wouldn't be any problem.

First off, I'll confess to being a language junkie. I like to learn programming languages, and I enjoy playing with them. Secondly, my bread and butter languages are C and Perl, which I like and dislike about equally.

So I've played with Python. Written a few small programs (some for personal use, a couple at work)... What none of these so-called Python advocates are mentioning is that programming in Python is fun.

I wish I could quantify it better, but I've actually found myself chuckling as a Python program came together.

Bander

p.s. Some of you people who think the block syntax in Python is too weird should take a look at Scheme or FORTH... Some of us used to program with a line-number oriented language without any real block structure at all. Back in those ancient days, we called it BASIC and liked it.:^)

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.

"VA can call itself whatever it wants to, but under the US Constitution it's a state".

Yes, and if they were trying to get the license interpreted under US law, that would probably be effective. They're not, it won't work, and you're a moron for not noticing that. Try not to dabble in legal work, you obviously don't have the powers of concentration needed.

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.

Python is a great language with a great user community! Please, do yourself a favor, download Python and gve it a try. I let the whitespace issue keep me from using Python for using Python, but my curiosity got me to try it. I'm glad I did.

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!

The main reason I chose to to GPL my latest open source project--the MaraDNS server [maradns.org]--was because I knew that there were some incompatibilities between the GPL license and the Python license. As long as the GPL may make it impossible to make a python module out of my code, I am not going to GPL it.

Instead, I made MaraDNS public domain. BTW, I use Python-style syntax for the mararc [maradns.org] file MaraDNS uses.

BTW, isn't it against the license for Python to have a gdbm module, since gdbm is GPL and not LGPL? And, is it not inappropriate to have Python KDE bindings or use Python in KDE programs?

My editor -- nedit -- allows me to select a region of text and shift its indentation in our out as a unit.
...
Vi doesn't.

Vi does support shifting the indentation of blocks of text. You clearly never graduated from the "if I can't learn it in 5 minutes it can't be any good" school of thought.

Try using the < or > keys in normal mode. You can also use those keys in combination with any movement command or object selection command to shift in/out the appropriate chunk of text. Indentation is based on the setting of shiftwidth.

In Vim you can also visually select a block (hit V then move around, or use the mouse to select) and then hit < to outdent or > to indent.

I program in MUMPS, a terse database/language written in the late sixties. It's a decent language, as far as that goes, but it also uses whitespace for blocking. I have seen more bugs due to stray spaces than misplaced braces (in C, Perl, etc). Plus, it makes it a pain in the ass when re-formatting huge blocks of code.

Remember the Golden Rule of Programming:

There is no language in which it is the least bit hard to write incorrect programs.

I use Python a lot. I use C a lot. As far as I'm concerned, the indentation issue is a non-starter --- you're going to indent your code *anyway*, otherwise you're not worthy of that paycheque. In C you have a bit of extra effort involved placing braces correctly. In Python you have a bit of extra effort involved getting the indentation right. When all's said and done, there's equal effort involved in each approach.

Remember: you cannot enforce good programming. You can only help. Python's pervasive dynamicity, data structures, class structures, module library all help good programming *far* more than the indentation style.

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.

Would you bitch and moan at C if some programmer decided he wanted to use straight braces instead of curly ones?

That wouldn't be the same thing, though, as curly braces are used in a few specific places, while spaces and tabs get used all throughout a program - whitespace separates EVERYTHING. I think people who dislike the whitespace-sensitivity tend to balk because of this, the same way they might balk if spaces were replaced with curly braces:
function{some_code(int{some_variable,int{some_othe r_variable){
{{{{{
{{{{{if{(some_variable>some_other_variable)
{{{{{{{{{{return{1;}
{{{{{else
{{{{{{{{{{return{0;}
{{{{}
Which braces are "separaters" and which are "block definers"? Even in this silly example, it should be relatively obvious if you LOOK at it, but it's not "intuitive".
I can understand where using whitespace, which is already used trivially throughout the code, to also represent something as significant as what constitutes a code block can be disturbing to some people...

For one thing, different tab stops screw up virtually every language, not just Python.

Only in terms of how "pretty" the source code is - none of the languages I've ever worked with (not that there are that many, nor that I'm a "master" of any of them, but...) actually had any problems due to varying tab sizes when it came time to actually compile and/or run the program

In other words, I think the problem is fundamentally that people who don't feel comfortable with Python mainly dislike the way it almost fits the definition of a bondage-and-discipline language [tuxedo.org] (except that I think the amount of useful stuff being written in Python easily disproves the "demonstrably inadequate for...even vanilla general-purpose programming" clause, regardless of whether I dislike the syntactical quirks of the language or not:-) ) and don't like feeling so constrained.

I suppose I could have gone on at some greater length about how *I* can't even necessarily match white space visually. Being uncertain of exactly how Python uses white space (I'm a Perl geek), I would suppose that there are means of formatting Python that are not immediately obvious to the naked eye. While that's also true of braces, at least I have editor functions to help me with braces. And if it were anything but whitespace, I *could* probably program vi to help me identify the delimiters.

Beyond that, at least braces are printable characters--I think it is important to focus the language on what can be seen rather than what is omitted or "invisible" in some sense, and I like the fact that most of the languages I program in are free form about white space (C, perl, shell).

Whitespace does doesn't seem to me to lend itself to ease of use as an active formatting element--what about environments that map tabs to 4 spaces instead of 8, what about (hypothetical) environments where tab doesn't even do what you'd expect, or requires tab settings to be made before use, etc. It seems to easy to get an extra space or tab in there where it could actively hurt you without being obvious to observe.

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.

And that's good for when you want to read your code. But style is bad for the general case of $programmer_y wanting to read $programmer_x's code. You address the first problem at the expense of the second. Python addresses the second problem at the expense of the first.

Plus, it makes it a pain in the ass when re-formatting huge blocks of code.

Interestingly, he specifically mentioned Knuth's condition: "once program units were small enough." Thus Python doesn't just make your code look a certain way, but also uh.. "encourages".. you to structure your code a certain way. (e.g. Lots of of little subroutines instead of long blocks with ifs nested 20 levels deep.) Now individual style is really going out the window...

The GPL is a "contract" in the informal sense, where "contract" is often used as a fancy or solemn way to say "promise". However, the law has a more stringent definition of "contract". (Or, if you're more cynical, the law provides all sorts of ways for you to make an agreement that looks like a contract but can't actually be enforced in court.)

If someone violates the GPL, they can still be sued -- but they would be sued for copyright infringement, not contract violation.--

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.)--

Python's biggest shortcomming (and I'm a Python programmer) is the whitespace issue. I like the idea of using indentation alone for control flow, but man, 90% of all bugs are because of tabs vs. spaces, one too many spaces, etc. And you always get a bizarre error message.

We need an Emacs Python mode that doesn't allow tabs and does something clever like only allowing indents to be a multiple of 2 (or 4-- when whitespace is significant, you want to indent further).

In whitespace hostile environments, a tool such as pindent.py [sourceforge.net] can be used. It adds commented block delimiters that preserve block structure when whitespace is messed with, and then converts back into executable Python source. The Emacs mode (and CVS, etc.) can be made to automatically apply these conversions, if desired.

So you see, in practice the use of indentation to delimit blocks is not impractical at all. It simply comes down to a matter of tastes, training, and preference.

I write a lot of C++ and Python code. I like both; the static vs. dynamic typing issues are HUGELY more relevant in determining which is better for a certain task, than block delimeters.

When I come across some code that's a bit hard to read because of formatting issues, I just load it into Emacs and run indent-region on the whole thing - now all the code is formatted just the way I most used to reading it.

Under a whitespace formatting system, I would have just destroyed the whole file instead of making it readable. I think it's better to let a programmer format code the way they can best read it.

I have written applications, not scripts, full scale major applications in both python and in perl (amongst other languages). And I have found python to be an absolutely fantastic languauge, whilst my troubles with perl still continue. I'm sorry, but any language that you have to call with special flags to get it to give you warnings of any kind is kind of lame in my book. Also namespace is such a problem, major applications can easily become buggy because of a small namespace issues. This just doesn't happen in real languages that have sane scoping.

Perl is good at what it was originaly designed for. Practical Extraction and Report Language, but don't bother if you wan't a multithreaded TCP/IP server. (26 lines of python - including spaces). And to be honest, python is just as easy as perl at that to.

If you really beleive you have an 'investment' in perl then you need to get a life and become a real programmer. The only difference between most 3rd generation languages is syntax, and within a couple of weeks, and with a good reference (i.e. www.python.org) behind you you can pretty much do anything.

There are multiple brace styles. There are not multiple indentation styles. It is indentation (which everyone agrees is good) that makes it a pain in the ass when re-formatting huge chunks of code.
-russ

I wonder if Eben has read the GPL. He says "Then anyone can receive a GPL'd program, modify it, and rerelease under a GPL with an Unfeedonian-law-applies clause." How could they do that? You can't modify the GPL. In fact, leaving the jurisdiction unstated allows someone to interpret the GPL under Unfreedonian law. If the GPL specified Massachussetts law, then it would be less uncertain.

But sometimes I wonder if the GPL wasn't devised to enhance uncertainty.
-russ

No. There is no opportunity for acceptance or rejection. A contract *must* be accepted by both parties. All that's needed is to put the software inside a tarball, then to put it inside another tarball that contains "README" which offers the use of the software conditioned upon acceptance of the license. If you unpack the inner tarball, you have accepted the license. If you don't accept the license, you don't unpack the tarball. You may, if you wish, have a software agent which accepts the license for you. We can write a standard for the form of the license, so that in practice, you run "license" instead of "tar xfz". And you have pre-configured license with the licenses you will accept automatically.

RMS doesn't like this idea because the contract could specify terms of use, and he is unalterably opposed to any kind of use license (and I don't blame him). The solution is to oppose bad contracts, not to hide your head in the sand and pretend that users (not distributors) have disclaimed warranty.

I don't want to warrant use. Legally, right now, most of us do. This should be fixed.
-russ

In a non-UCITA state, you are wrong. Existing law requires that you have a chance to review the license, and accept or reject it. Current software distribution technology does not give you this opportunity. Once you have unpacked the software, it's too late. They're still bound by the license. You now have title to a copy of the software, and the copyright terms (the GPL) does not apply to you.

Those elements absent in the GPL are present in shrink-wrapped software. You are free to reject the terms presented to you and return the software to the store.

In Virginia, a UCITA state, you are allowed to condition a license upon performance. So that once the software has been installed, you may claim that the user should have gone looking for a license, and if they failed to, it's their tough luck. However, UCITA also requires a warranty on all software, so that the GPL terms have no effect.

In Maryland, also a UCITA state, there is a bill on the governor's desk which grants an exemption to open source software for which no license fee is charged. Once that law is signed and goes into effect, the GPL terms will be binding upon users (as opposed to distributors who are bound when they copy the software).

IANAL, but I had dinner with two lawyers (and if you're really well-informed, you can venture a good guess as to who they are) on Wednesday night. If you think hackers use impenetrable jargon, just listen to a pair of lawyers in the middle of a legal hacking session! It's enough to make your head spin.

BTW, it's not the whole GPL that can't be enforced. It's only the waiver of warranty.

Also BTW, try convincing Eben Moglen and/or RMS that the GPL is actually a contract. It isn't. They didn't intend it to be, and it wasn't written in the form of a contract.
-russ

Yes, the license is still the same. However, it's not a valid contract, and you need a contract to disclaim warranty.

Unless you're GM or GE, you're not going to be able to change the terms of a shrink-wrap license. However, any store that doesn't take back shrink-wrapped software is going to face great pressure from the industry. The validity of the shrink-wrap license is predicated on your ability to refuse it. If, in fact, you have no right, then the license is not a contract, and you're not bound by it.

And that's another thing: jurisdiction. The FSF claims that any license which dictates jurisdiction is not compatible with the GPL, because doing so imposes extra restrictions on the GPL'ed software.
-russ

Re-read it. That's not what he's saying. He's saying that privity -- and contract law -- is not necessary, because copyright law governs copying.

Note how the GPL says "This software is yours to use." That means that no conditions apply. It also means that the disclaimer of warranty (which requires agreement to a contract) does not apply to anyone who merely uses the software and refrains from copying it.
-russ

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.

Actually, you just shot yourself in the foot with that comment, who needs to mtch braces when you can just look at the screen and see where your block of code begins and ends!!!! When I am modifing poorly written C, or C++ code that is not formatted correctly, I find that useful, but if it had been in python, I would not have to worry about that in the first place!

Your argument is just like saying, "the biggest problem that I face with java, is the portability of the code... it's extrememely difficult tow rite a "stand-alone" application that be distributed..." No CPU executes a java class file, for anyone to run your java program you need to have java installed, or give the the source. The same is true with python. Anyway, since most people have java VMs installed, another simpler way to accomplish this is to use Jython. Write in python, compile into javabyte code and just distribute the class files.

I have been studying up on the R language lately, an open source version of S, the statistical language of John Chambers, and I've noticed that R and python are awfully similar in their basic, and novel, language concepts. The R homepage is at

http://www.gnu.org/software/r/R.html

The omegahat project, at www.omegahat.org, has developed interfaces between R and python, as well as packges to interface between R and Perl, and R and Java.

Anyway, I would have liked to hear Guido's thoughts on R or S and how they compare to python. The correspondence of concepts in the two languages in amazing to me, given how different their origins were.

commonwealth \Com"mon*wealth`\ (?; 277), n. [Common + wealth well-being.] 1. A state; a body politic consisting of a certain number of men, united, by compact or tacit agreement, under one form of government and system of laws.

My editor -- nedit -- allows me to select a region of text and shift its indentation in our out as a unit. Jcc ("Code Crusader") also allows me to do this. As does Visual Studio's editor, when I have to use it.

Try using the < or > keys in normal mode. You can also use those keys in combination with any movement command or object selection command to shift in/out the appropriate chunk of text. Indentation is based on the setting of shiftwidth.

Thanks! I appreciate the help.

You clearly never graduated from the "if I can't learn it in 5 minutes it can't be any good" school of thought.

Fuck you! You clearly never graduated from the "I get to be an intolreable prick because it makes me feel better about my own suprtiority" school.

In Vim you can also visually select a block (hit V then move around, or use the mouse to select) and then hit to indent.

Thanks! That's useful. I still won't be using vi for my day-to-day editing.

But, I do have one quibble, the same quibble I've had with Python from the outset. Using whitespace blocking to mandate code structure forces the programmer to the language, and not the other way around. I like my code to fit my style.

I agree completely. Guido says "Don't you hate code that's not properly indented?", and I do. I also don't like reading code that is poorly documented, doesn't use descriptive identifier names, or uses 300 line methods that should be broken up. However I would be very annoyed if a compiler were to refuse to compile code without comments, or forbid variable names of less than 6 characters, or limit methods to 50 lines. Maybe this is a result of my libertarian views; I don't want a nanny state, and I don't want a nanny compiler.

And more importantly, there's no way (that I know of) to put an RSA Python script in a 4-line sig block...

I must disagree with your statement "No common text editor has a decent 'go to the end of the block' function." I use an exceptionally common editor (emacs) and in Python major mode skipping to the end of the block is as easy as "C-M-e". Also I *never* have a problem with Emacs in Python mode -- all my indentation is handled completely transparently. It sees that I'm starting a block and handles my indentation automatically, and leaving the block is as simple as hitting the backspace key.

If I understand correctly, the PythonWin IDE for MS Windows also includes this functionality. Your first argument is a straw man and factually incorrect.

Your second argument regarding spacing problems simply happens very rarely in Python. There is one indentation style (with the exception that the number of spaces is variable), and using such simple tools as Tab Nanny nips them in the bud. Just like C programmers remember to curly brace correctly, Python programmers indent correctly.

Anyway, interesting language war thread. I use Python and Perl extensively in my work, and find Python eminently more readable. It is also far easier to maintain, and is my language of choice for prototyping most new applications these days.

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.:^)=

You can create a Debian package for it. There's nothing stopping you. In fact, Debian does not require GNU licenses. Debian GNU/Linux is referred to in this manner because of the FSF-recognized name for Linux. Likewise, Debian is NOT an FSF distribution. It's close, but software that is distributed in the "main" repository (the free-software repository) must adhere to the Debian Free Software Guidelines (DFSG [debian.org]); it does not necessarily have to be GNU [gnu.org] GPL [gnu.org]

From the DFSG:

10. Example Licenses

The "GPL", "BSD", and "Artistic" licenses are examples of what we consider free.

Where you will run into problems, or rather where you had run into problems, was with Python 1.6[.1]. Debian refused to package this in "main" for the same reasons its license conflicted with GPL. However, Debian doesn't have the same hangup that FSF has with Python 2+. Just look in the package listing for testing/unstable.

Regardless, I want to clear something up here. If your program depends upon software or libraries that are released under a license that prevents those tools from being distributed in the "main" repository, it does not stop you from packaging your software and including it in "contrib". Your software will not be forced into "non-free" if your license is DSFG-compliant.

Absolutely. If you can't handle using character 13 rather than character 59 to end a statement and character 100 rather than character 123 to start a block, you'll be totally screwed when you see the way prolog does it.

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.

Why doesn't someone just go ahead and write a version of python that uses braces instead of indentations? All it would take would be a simple text filter to convert braces into indentations (and vice versa).

I have to commend FSF for wanting to make GPL perfect and not have any loop-holes or what not but this is going a bit too far. They need to make up their mind and from the sounds of this article they keep changing what certain things mean. How can we expect Open Source/Free software to evolve and become a real continder in the market place if we can't even agree on a license. I love the idealism but this sort of thing needs to stop. I think we all want the same thing, which is choice in the marketplace and real compitition. These sorts of fights will be just one more reason MS users can brush us off

As far as the State thing, the Python license has a good point, not all states honor the general disclaimer law. This could cause problems for GPL and FSF would be smart to take that into consideration.

[In MUMPS,] "I have seen more bugs due to stray spaces than misplaced braces"

When you try to run a program with inconsistent spacing, python will complain about it - the simple program:
print "First Line"
print "Second Line"
will cause an error when you try to run it, because the second line isn't indented properly.

There's also tabnanny, a standard module that's designed to check for inconsistent indentation. From its doc string: "The Tab Nanny despises ambiguous indentation. She knows no mercy."

I think I would expect more insightful commentaries from someone that has written books published by Oreilly than "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.".

That's kinda too generalized and/or clueless, isn't it?

It is a generalization, but not, it is not clueless. The generalization is, of course, that you have to be a Perl expert in order to be able to read the Perl code of others. It is a generalization, however, that does very much reflect the state of the Perl language--even if it does not hold for every single piece of Perl source code. No one in their right mind would include Perl code in large scale software systems. That's an absolute, not a generalization. Perl has quite simply been applied to problem domains way outside of its core strengths and has, quite honestly, outlived its usefulness.

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.

I think that FSF is very justified in not considering the Python lic GPL compatible.

Put in the light that once it is compatible they have to live with it FOREVER just like Eben said.

That is not a decision they should take lightly and it is a good thing to take caution when you are talking about a Lic which thousands and thousands of projects depend on. Something such as this can undermine the integrity of everything.

The GPL needs to stand up in court but declaring it legal and then watching the Python lic go down in flames because someone abused it on their own software doesnt help GPL any at all since it was declared "compatible".

The reasons and scenarios are legally to far fetched for me to properly illustrate but unless you have been a lizard under a rock you absolutely know how extreme and far fetched software lic and the law can be.

It is not something, even if I dislike the GPL on principle, that should be taken lightly if FSF wants to see that the GPL keep as much integrity as possible until it is outright challenged in court or some such. Play it safe.

BTW: I think posting something like that obviously written only for a small and closed audience is not cool... Not that it wasnt expected given how the letter was written.

The GPL is all fine and dandy, but it causes problems. The point of the GPL is to spread it's ideology virually. That's great. But when it's not what you want, find something with a more liberal, tolerant license (LGPL included) or do your own implementation.

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.

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:

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.

There's something wrong with the Slashdot's questions collecting system. Some of the questions that Guido has answered to were not very interesting, and better questions had been submitted by slashdot contributors. But, because they were not among the first to post their questions, they have not been moderated up, and thus their questions have not been picked.

There were many fascinating issues to discuss with Guido that have been completely missed. Things more relevant than "thoughts or Ruby?", "Favorite MP sketch?", etc... Guido is a fairly discrete person, and it's always kinda difficult to know what he thinks about functional programming, typing, Python/Java complementarity or rivalry, etc... This would have been a great occasion, and we missed it.

You *like* Mumps? I put it slightly higher than Befunge for readable...

I suspect forced indentation is something of a holy war issue. I'm repulsed by it myself but I can see it having advantages that don't necessarily apply to me. I really don't think it's a visual ergonomics issue at all, just a question of personal taste. (Of course, I happen to consider PostScript syntax to be elegant, so who am I to talk?)

The Cheese Shoppe is a classic. A man comes into a Cheese Shoppe and starts asking for different kinds of cheese. The shoppe owner responds in various ways that he is out of them (including a request for Cheddar to which he replies that he doesn't have "much call for it". At one point Cleese says, "This IS a cheese shoppe, isn't it?" the owner replies "Oh, YES sir, the finest in the area". Cleese asks him on what criteria he is basing that assumption. The owner says, "It's so CLEAN!" Cleese mutters "Well it's certainly uncontaminated by CHEESE!" When he finally says he DOES have a requested cheese it is with the proviso that it's "a bit runny today". When the buyer says that is fine "I like it runny", the shoppe owner looks under the counter and cries "Oh, the cat's eaten it." The store owner finally admits that he has no cheese and has been purposely wasting the man's time. Cleese says "alright, that means I'll have to shoot you, then." BLAAAM. End of skit.
PS....not sure that MOVIE SCENES qualify as skits (which were part of the weekly series), but then that's mostly all the movies are is a series of skits with a common thread. . . so I'll let it go this time.

Didn't he also say that we should all go and learn how to code in machinecode if we have more than a casual interest in computers? Or was that someone else?

The main problem, though, is long lines of code. What do you do when you hit the 80 character mark? The JavaScript implementation sucks, it's no good if wrapover is also valid on its own... That's the annoying bit.

The easiest way to GPL compatibility is to release the code as dual license, under GPL.

If the only problem really is that CNRI doesn't want to be sued, the easy way to do this for CNRI is to license python to someone who takes the risk to be sued, for example our friend Zooko, who then releases it under GPL.

Maybe, this ceremony would have to be repeated every release of python.

First, let me say that I LOVE Python... I use it for almost all of my application development.

However, the biggest problem that I face is the portability of the code... it's extremely difficult to write a "stand-alone" application that can be distributed. Sure, there's the Freeze tool, but it's a pain to use, and hard to configure properly.

If I'm writing an app that I want others to use (on a non-Linux system), I'll usually choose C/C++ instead, because I know that I can easily send it out. Otherwise, I end up with an application that needs three installers... (Python, Win32, mine).

"I will give you this hamburger on the condition that you don't put cheese on it."

That sounds like a contract to me.

A contract doesn't necessarily need to involve mutual benefit, or an exchange of anything. A contract is simply an agreement undertaken by two or more parties. The GPL is exactly that: an agreement:

Contract \Con"tract\, n. [L. contractus, fr. contrahere: cf. F.
contrat, formerly also contract.]
1. (Law) The agreement of two or more persons, upon a
sufficient consideration or cause, to do, or to abstain
from doing, some act; an agreement in which a party
undertakes to do, or not to do, a particular thing; a
formal bargain; a compact; an interchange of legal rights.
--Wharton.

Unfortunately, Guido wasn't asked, and didn't provide answers, about efficient compilation for Python into standalone executables. There are actually efforts underway, but it would be nice to find out more about his thinking on them.

In principle, Python could be compiled like C, C++, Java, Fortran, Eiffel, etc. into standalone executables. That would both simplify deployment and (if done well) improve speed. Previous attempts at this have not been particularly popular or successful, however.

Insulted? In what way? Can you provide details? How can you "insult" a company anyway?

He should have praised [TrollTech] diplomatically for their decision, as this was a victory for the FSF and the GPL.

You mean he should have praised TrollTech for their decision not to go out of business? TrollTech's hand was forced: without KDE, Qt would be just one of a dozen obscure commercial toolkits. And without changing Qt to a GPL license, KDE would have had to come to an end.

What this whole thing shows is that RMS's care and stubbornness in designing the GPL has paid off. Without it, TrollTech would have been able to hijack KDE, a major high-quality open-source project, for their commercial purposes.

As for TrollTech, I'd continue to view them with suspicion. Their vision seems to be that any commercial user of open source software should pay some commercial company, and they seem eager to want to do whatever they can to make Qt an integral part of whereever Linux goes. That is not the kind of vision many supporters of open source have, and pragmatically, it is also very bad for the long term viability of open source software.

I had two xterms open here on my NT4 box here at work. One open to a Solaris box, one to my captive (two-machine subnet composed of a crossover cable) NetBSD box (Net-help doesn't know about it, hooray!). On both command lines I was able to type ed and enter an editor.

It isn't my editor of choice, but it's indeed the standard editor on Unix. If you've got a Unix-like system that doesn't have 'ed' on it, you've got a broken distribution.