Slashdot Mirror

Shane Hathaway writes: "I'm sure the slashdot readership will be happy to learn that Python is now compatible with the GPL. It's a bugfix for Python 2.0 but a similar release is planned for Python 2.1."

Shane Hathaway writes: "I'm sure the slashdot readership will be happy to learn that Python is now compatible with the GPL. It's a bugfix for Python 2.0 but a similar release is planned for Python 2.1."

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)

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)

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)

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)

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)

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)

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)

avdi asks: "BeOpen.com was once one of the crop of promising free-software based dotcoms, basing their business on selling corporate support contracts for the open-source development tools they also maintained. They were even the center for Python development at one time. Now, however, Python has moved on; their web site is out of date; their supported software cannot be downloaded; and they are unreachable via email. So, has BeOpen.com silently gone the way of many other dotcoms in these hard economic times, and if so, what has/will become of the open-source software they once maintained?" I tried calling the contacts listed for BeOpen.Com, and the numbers for both the administrative and techical contacts were disconnected. Not good news for those interested in the site, but maybe the software projects they housed managed to find new homes. One can hope...

"I recently became interested in a couple of XEmacs-based open-source development tools, namely Infodock and OO-Browser. A quick search on Freshmeat directed me to a page at BeOpen to download these tools. The BeOpen page was simply the top-level of a Freshmeat-like open-source application directory; when I finally drilled down to the listings for Infodock and OO-Browser they directed me right back to Freshmeat. This despite the fact that BeOpen has some lengthy product pages providing overviews, contract prices, and documentation for these tools. Everything, in fact, except a link to the source tarballs. ftp.beopen.com was unavailable. Eventually I tried emailing them at one of the addresses listed on the product pages. The email bounced.

Does anyone know of other repositories where it can be found? Is there any other group who might take on maintenance of these, software packages?"

This week's interview is with Guido van Rossum, a man who, as they say, needs no introduction. (Not around here, at least.) To learn a bit more about him, check his personal page. You might want to ask him about Python 2.1, which was released today. One question per person, please. We'll send 10 of the highest-moderated ones to Guido about 24 hours after this post went up, and will run his answers as soon as he gets them back to us.

This week's interview is with Guido van Rossum, a man who, as they say, needs no introduction. (Not around here, at least.) To learn a bit more about him, check his personal page. You might want to ask him about Python 2.1, which was released today. One question per person, please. We'll send 10 of the highest-moderated ones to Guido about 24 hours after this post went up, and will run his answers as soon as he gets them back to us.

chipmunk writes "My prayers have been answered! Larry and Guido have joined forces to produce Parrot, what will surely become the best language ever written. The power of Perl and the sanity of Python. The Py3K and Perl 6 development are merging, with Jeremy Hylton and Dan Sugalski as joint development leads. Read more in the press release on use Perl;, and see a joint interview on perl.com!"

It's about time. It's like the right brain and left brain are working together, at long last. O'Reilly has already inked a deal to publish Programming Parrot, and Yet Another Society is set to merge with the recently launched Python Software Foundation. Both Guido and Larry will be working for ActiveState.

The Open Source Initiative has modified their official definition of an open source software license. The change itself is minor, but they're also calling for more input on other possible improvements to the definition - see below for more.

Russ Nelson writes: "We changed the Open Source Definition today. Some people had the idea that "may not" in Section 1 meant that they had a choice. We changed it to "shall not". Other changes may be in the offing. The OSD says nothing about use licenses or patents, for example.

"A use license is largely unenforcable by itself. How can you tell what people are doing with software if anyone is allowed to redistribute it to anyone they want? Some parties have tried to enforce a use license by requiring the non-removal of certain parts of the code. This is, in itself, already prohibited by the OSD, however it's best not to rely on indirection to keep use licenses off Open Source software.

"Patents are a problem that have been anticipated by some licensors. In part the furor over the APSL 1.0 was produced because they reserved the right to revoke the license if it turned out that they were licensing software patented by someone else. A number of new licenses have specifically included terms that require contributors to license any applicable patents. And yet the OSD does not require this. What is the good of an OSI Certified piece of Open Source unless you can use it? And you certainly shouldn't allow someone to sue any contributor over patent infringement and still have a license to use the software.

"Are there other lapses in the Open Source Definition? Send them to me and I'll summarize for the board. Speaking of the board, Brian Behlendorf (Apache/Collab) and Ian Murdock (he put the ian in Debian/Progeny) have resigned, and Guido van Rossum (creator of Python) and Michael Tiemann (co-founder of Cygnus) have taken their place."

Qbertino writes: "A guy that calls himself "matrixnan" introduced this project on NANs Blender homepage. It's gonna be a GPLd 3D GUI for Linux using Blender as construction kit. Blender is a professional freeware 3D Animation/Modelling/Applicationkonstruction kit that features Python as Plugin language (Plugins are a big deal in the 3D business). Coding of the Project uses/will use Python, C and C++. Unlike the 3Dsia project it sticks more closely to the 3rd person perpective of the classical Desktop and avoids going to deep into VR and the acompanied problems. It uses NANs reference grade 3D construcion kit and seems to be on its way quite well - and thus will probably see usability quite soon. Also take a look at some serious eye candy - the screens." I'm a little more skeptical about time frames for actually being able to run this thing, but there are lots of interesting ideas to think about.

wildgift writes: "This is probably not news to some young people, but some of the older people here should be aware that Microsoft runs a wide ranging IT/Programming curriculum project, called Mainfunction, that teaches young people to program using Microsoft tools. The obvious issue is: is anyone leveraging the education-friendly Unix environment to create a similar program? This is a huge opportunity. So far, I've only found this Python article." If Microsoft is getting their tools in the hands of the programmers of the future, what can we do to achieve the same? Wouldn't it be much better if kids could take a look at development on several different platforms so that they can better use the technology when they are professionals rather than settling on "what they know"?

atallah writes: "It would appear that the long awaited Python 2.0 was finally released today. The front page of the Web site has the announcement." According to that announcement, Python 2.0 will receive minor-version updates around every 6 months, even as work begins on the shoot-for-the-moon Python 3000. For the curious, here's the list of what's new in 2.0; the list includes "full XML support and several forms of new syntax," as well as the BeOpen label.

jhylton writes "How's this for a rapid release schedule? Python 2.0 beta 1 is now available from BeOpen PythonLabs. There is a long list of new features since Python 1.6, released earlier today. We don't plan on any new releases in the next 24 hours ."

tonys1110 was one of the first to tell us that Python ^[?] 1.6 Final has been released unto the world. They've got a bit about the license, and of course, the obligatory "What's New".

realberen writes: "Visual Python 0.1 is released. Quoting the Web site: Visual Python, at its current stage of development, is a set of components aimed at GNOME and KDE application developers to enable them to easily add scripting capabilities to their applications. Ah, how I love Python! :)" Does this neatly counteract the argument that MS Office applications are necessary for complex, scripted integration (via Visual Basic)?

Kailden asks: "I've run across several references to Ruby, a scripting language that claims to be a hybrid of Perl and Python. Supposedly, this language has taken Japan by storm. I'm looking for Slashdot's verdict before jumping in. Has anyone outside the Ruby site used this language? What advantages/disadvantages have you found?"

Python is an object-oriented scripting language, similiar in ideas (if not in style) to Perl. It's getting more and more popular, as people discover the benefits brought by its simple style. It's a natural under Windows, thanks to good object-orientation. Like many free software projects, though, the Windows port of Python has suffered from poor documentation. Until now, that is. [Updated 15:00GMT by timothy -- fixed link to tutorial.](Read more.)

Python Programming On Win32 author Mark Hammond & Andy Robinson pages 652 publisher O'Reilly, 01/2000 rating 8.5 reviewer chromatic ISBN 1-56592-621-8 summary A great introduction both to programming Python under Windowsand to COM programming for non-Windows programmers.

What's Good?

Python has made programming under Win32 really, really easy. Not that it didn't need to be easy before -- it's just that nobody knew how it worked. This book knocks that for six. It covers a basic introduction to Python, builds a slightly more advanced tutorial on that and then covers a load of other topics to finish off. The really big secret is that the information inside isn't just for Windows, though. Quite a lot of it is applicable elsewhere. Topics like printing output to PDF files, using POP3 and HTTP in python would be a useful addition to anybody using Python who isn't already aware of these things. If you've just started learning Python, there will be tons of ideas for you to experiment with.

But the big thrust of the book is COM (or OLE, or ActiveX or whatever it's called this week). The book slides you gently in, explaining the ideas behind OO programming that you need to know to take advantage of it, before presenting simple demos of what COM can do and how it was achieved. Then it takes you on to bigger and better things, and specifically to an accounting system that was developed using Python/Win32. Please ignore the word "accounting" in the previous sentence! It's just an application that the book uses to demonstrate Python and COM working together and ways of using it (e.g. shoveling data straight into Excel from the aforementioned accounting system).

The remaining part of the book has plenty to sink your teeth into, from Internet to serial communication, along with little things that you'll soon begin to appreciate as essential, like user management using Python. If you suddenly want to change all of your users somehow, you'll be grateful that you can do it programmatically.

The book brims with practical ideas that focus on one programming paradigm that a lot of people seem to forget about: Getting Things Done. Also, it was written by the author of the code, and it shows.

In short, this book brings the Windows world the kind of programmability that Unix people have come to expect. And the kind that Unix people can expect to see, too; from what I've seen of Bonobo, it's rather similiar to COM.

What's Bad?

No book is without its flaws, and this one has a couple. My biggest bugbear would be with the Python tutorial section: At 8 pages, it's just not long enough for someone who isn't accustomed to Python. While the online Python tutorial is reasonable, I would have expected a better introduction, given that Python isn't as well known as it could be. That could put some people off the book.

My other complaint is that the book is too small. Well, no -- it's just right actually, and has the nice bendy RepKover thing. But the book is burdened with so many topics that at times some subjects feel like they could have used a bit more in-depth treatment, or more extended examples. The authors must have felt the same way, since at the end of most chapters, there are pointers to further information, which is actually pretty useful.

Summary

I'm sure that there are a lot of Slashdot readers who run Windows on a regular basis. I think that this book will help a lot of them understand their environment better and help them tame it. It's also useful for die-hard Unix-heads like me, who are suddenly faced with a need to get things done under Windows and would like a clearer explanation of what they are up against, as well as some interesting ideas for when they return. Lastly, it's definitely useful to anybody already using the Python Win32 extensions, because the documentation that comes with those extensions cannot compare to this lovely, practical book.

Table Of Contents

1. Introduction to Python

   1. What is Python?
   2. Python Language Review
   3. Python on Windows
   4. Integrated Development Environments for Python
   5. Introduction to COM
   
   

2. Building an Advanced Python Application

   1. A Financial Modeling Toolkit in Python
   2. Building a GUI with COM
   3. Adding a Macro Language
   4. Integration with Excel
   5. Printed Output
   6. Distributing Our Application
   
   

3. Python on Windows Cookbook

   1. Advanced Python and COM
   2. Databases
   3. Working with Email
   4. Using the Basic Internet Protocols
   5. Windows NT Administration
   6. Processes and Files
   7. Windows NT Services
   8. Communications
   9. GUI Development
   10. Active Scripting
   11. Extending and Embedding with Visual C++ and Delphi
   
   

4. Appendixes

   1. Key Python Modules and Functions
   2. Win32 Extensions Reference
   3. The Python Database API Version 2.0
   4. Threads
   
   

Python is an object-oriented scripting language, similiar in ideas (if not in style) to Perl. It's getting more and more popular, as people discover the benefits brought by its simple style. It's a natural under Windows, thanks to good object-orientation. Like many free software projects, though, the Windows port of Python has suffered from poor documentation. Until now, that is. [Updated 15:00GMT by timothy -- fixed link to tutorial.](Read more.)

Python Programming On Win32 author Mark Hammond & Andy Robinson pages 652 publisher O'Reilly, 01/2000 rating 8.5 reviewer chromatic ISBN 1-56592-621-8 summary A great introduction both to programming Python under Windowsand to COM programming for non-Windows programmers.

What's Good?

Python has made programming under Win32 really, really easy. Not that it didn't need to be easy before -- it's just that nobody knew how it worked. This book knocks that for six. It covers a basic introduction to Python, builds a slightly more advanced tutorial on that and then covers a load of other topics to finish off. The really big secret is that the information inside isn't just for Windows, though. Quite a lot of it is applicable elsewhere. Topics like printing output to PDF files, using POP3 and HTTP in python would be a useful addition to anybody using Python who isn't already aware of these things. If you've just started learning Python, there will be tons of ideas for you to experiment with.

But the big thrust of the book is COM (or OLE, or ActiveX or whatever it's called this week). The book slides you gently in, explaining the ideas behind OO programming that you need to know to take advantage of it, before presenting simple demos of what COM can do and how it was achieved. Then it takes you on to bigger and better things, and specifically to an accounting system that was developed using Python/Win32. Please ignore the word "accounting" in the previous sentence! It's just an application that the book uses to demonstrate Python and COM working together and ways of using it (e.g. shoveling data straight into Excel from the aforementioned accounting system).

The remaining part of the book has plenty to sink your teeth into, from Internet to serial communication, along with little things that you'll soon begin to appreciate as essential, like user management using Python. If you suddenly want to change all of your users somehow, you'll be grateful that you can do it programmatically.

The book brims with practical ideas that focus on one programming paradigm that a lot of people seem to forget about: Getting Things Done. Also, it was written by the author of the code, and it shows.

In short, this book brings the Windows world the kind of programmability that Unix people have come to expect. And the kind that Unix people can expect to see, too; from what I've seen of Bonobo, it's rather similiar to COM.

What's Bad?

No book is without its flaws, and this one has a couple. My biggest bugbear would be with the Python tutorial section: At 8 pages, it's just not long enough for someone who isn't accustomed to Python. While the online Python tutorial is reasonable, I would have expected a better introduction, given that Python isn't as well known as it could be. That could put some people off the book.

My other complaint is that the book is too small. Well, no -- it's just right actually, and has the nice bendy RepKover thing. But the book is burdened with so many topics that at times some subjects feel like they could have used a bit more in-depth treatment, or more extended examples. The authors must have felt the same way, since at the end of most chapters, there are pointers to further information, which is actually pretty useful.

Summary

I'm sure that there are a lot of Slashdot readers who run Windows on a regular basis. I think that this book will help a lot of them understand their environment better and help them tame it. It's also useful for die-hard Unix-heads like me, who are suddenly faced with a need to get things done under Windows and would like a clearer explanation of what they are up against, as well as some interesting ideas for when they return. Lastly, it's definitely useful to anybody already using the Python Win32 extensions, because the documentation that comes with those extensions cannot compare to this lovely, practical book.

Table Of Contents

1. Introduction to Python

   1. What is Python?
   2. Python Language Review
   3. Python on Windows
   4. Integrated Development Environments for Python
   5. Introduction to COM
   
   

2. Building an Advanced Python Application

   1. A Financial Modeling Toolkit in Python
   2. Building a GUI with COM
   3. Adding a Macro Language
   4. Integration with Excel
   5. Printed Output
   6. Distributing Our Application
   
   

3. Python on Windows Cookbook

   1. Advanced Python and COM
   2. Databases
   3. Working with Email
   4. Using the Basic Internet Protocols
   5. Windows NT Administration
   6. Processes and Files
   7. Windows NT Services
   8. Communications
   9. GUI Development
   10. Active Scripting
   11. Extending and Embedding with Visual C++ and Delphi
   
   

4. Appendixes

   1. Key Python Modules and Functions
   2. Win32 Extensions Reference
   3. The Python Database API Version 2.0
   4. Threads
   
   

uffbeerday iteswray: "Erethay isyay ayay 1.6 ersionvay ofyay Ythonpay inyay alphayay. Inyay additionyay, eythay avehay ayay eduleschay orfay uturefay eleasesray andyay omesay arningsway aboutyay odecay eakagebray expectedyay ithway osethay eleasesray. Ityay ookslay ikelay ethay ocumentationday illway aglay ethay eleasesray ayay itbay." Apparentlyyay, ityay illway eakbray omesay odecay. Ethay eleaseray otesnay escribeday emthay asyay "olklorefay APIsyay (atthay ereway evernay ocumentedday oryay endorsedyay utbay everthelessnay ereway acceptedyay andyay inyay ommoncay useyay)." Ethay otesnay onyay 1.6 alsoyay aylay outyay anyay ambitousyay oadmapray owardtay Ythonpay 3000.

jbc writes "According to Guido, DARPA has accepted an initial version of a proposal called Computer Programming for Everybody. The idea is to use government money to develop and promote a Python-centered curriculum for high schools and colleges. He defends the choice of Python, as opposed to languages like Perl, Tcl, or Visual Basic, because the latter are, in his view, 'too cluttered with idiosyncracies' to be effectively taught to beginners. " This is actually something I've been peripherally involved with. My CS teacher and I have been talking with Guido about this (I go to Yorktown, one of the schools mentioned in the proposal) - I can tell you firsthand that C++ is just too difficult for first-year CS students in high school, whereas Python is quite simple and elegant. Hopefully, this program will serve as a nice intro for students so that they can get started in programming and perhaps move on to other languages as they become more and more accustomed to the practices of programming.

WillWare writes "Here's a nifty microcontroller project being done by Ryerson Amateur Radio Club in Canada. They are building a SIMM board with a Motorola Dragonball (same processor as the Palm Pilot), 4 meg of flash, 8 meg of DRAM, some digital I/O pins, ports for Ethernet and RS-232, and able to drive a 320x240 LCD panel. This board is intended as a target for their MMU-less Linux port, which has previously been running on Palm Pilots. There has been mention on the mailing list of the possibility of running a Python interpreter on this board. This would be a huge win for rapid app development on embedded controllers. "

Kragen Sitaker has written a brutal reply to the story Sengan posted yesterday on the The Open Source Acid Test. It goes down and point by point shows the factual errors and fud in the story. It pleases me greatly to post this feature. Check it out. The following was written by Slashdot Reader Kragen Sitaker

I read Ted Lewis's article, _The Open Source Acid Test_, on your web pages.

I was appalled that an organ of a prestigious international society like the IEEE would publish such error-riddled, poorly-researched, deliberately deceptive nonsense. It's as if the _New England Journal of Medicine_ had published a case study of a zombie animated by voodoo!

The author did not cite sources for any of his dubious statistics, and they are therefore hard to disprove. Given the remarkable lack of factual accuracy in the article, I doubt that they have any basis in fact.

To begin with the most obvious errors:

1. Linus Torvalds's name is not Linus Torvold.
2. Applix, Tower Technology, and NewMonics do not sell open-source software.
3. There is no such company as "Walnut Creek Stackware". www.cdrom.com belongs to Walnut Creek CDROM. There is no such company as "Tower Tech JVM". www.twr.com belongs to Tower Technology, which sells a (non-open-source) JVM. There is no such web site as www.debian.com.
4. www.python.org is operated by the Python Software Association, not CNRI, although it is currently hosted on CNRI's network.
5. Several of the "commercial enterprises" listed in Table 1 are not commercial enterprises at all. www.hungry.com, www.python.org, and www.debian.org are all operated by nonprofit organizations. The Corporation for National Research Initiatives, which was incorrectly listed as operating www.python.org, is actually a not-for-profit research organization.
6. It is absurd to say that Unix was the foundation for Hewlett-Packard and IBM, as Lewis does in his introductory paragraph. Both companies had been established for more than thirty years when the first line of Unix was written.
7. On page 126, Lewis claims that the open-source community admits that its organizational structure is weak. The evidence he adduces is a quote from a document published on www.opensource.org. What he doesn't tell you is that the document is *a leaked internal Microsoft memo*. Unless Lewis missed the 115 references to Microsoft in this document and also failed to read the introductory paragraphs, the only reasonable conclusion is that he is being deliberately deceptive.
8. On page 125, Lewis claims that "Currently, Linux's installed base numbers 7.5 million". As usual, he cites no source. However, the most widely-cited source for such figures is Robert Young's paper, Sizing the Linux Market eight different data sources to obtain an estimate of between five and ten million Linux users. However, this paper has a date of March 1998. If Linux's growth had continued to double yearly in 1998, as it did from roughly 1993 to 1998, the number of Linux users would be between ten and twenty million.
9. On page 128, Lewis says, "Windows NT market share smothers all Unix dialects combined". According to International Data Corporation's Server Operating Environment report, Unix and Linux together had 34.6% of the server market in 1998, while Windows NT had 36%. See more information. The actual number of server Linux shipments IDC tallied in 1998 was only three-quarters of a million; that suggests that if you include people installing multiple servers from the same CD and installing from Internet downloads, you would find that Linux's server market share is much greater than Windows NT's.
10. Lewis remarks, "With few exceptions, open source software has never crossed the chasm into the mainstream without first becoming a commercial product sold by a commercial enterprise." Does he think that Linux is not a commercial product sold by commercial enterprises? If not, there are literally dozens of "exceptions" to this statement -- Perl, Apache, sendmail, BIND, Linux, Tcl/Tk, Berkeley DB, Samba, the X Window system, FORTH, GNU Emacs, and trn, for example. Many of these became popular before they were commercially sold at all.
11. Lewis misstates the business case for Linux and "its open source software cousins". According to Eric Raymond -- whom Lewis quotes extensively elsewhere in this article -- a much more compelling business case is founded on the better quality of the software, choice of suppliers, choice of support and maintenance, freedom from legal exposure and license tracking. More details are available at opensource.org/for-buyers.html.

These minor factual errors, so far, merely indicate that the author knows very little about the topic he writes about and is deliberately trying to mislead his readers; they do not directly undermine his conclusions. However, as I shall show, each of his supporting arguments consist of incorrect facts and lead to faulty conclusions.

One of the author's major contentions is that as Open Source software adds more features and becomes more comparable to proprietary software, it will lose many of its advantages. He cites as examples Linux's supposed lack of video card support, wireless LAN support, and "a good selection of productivity software."; he claims that Unix contains 10 million lines of code, while Linux contains only 1.5 million. On page 126, he says, "Maintenance and support grow more complex, and costs increase due to a scarcity of talented programmers. Success leads to features, and feature creep leads to bloated software."

With regard to video card support, it is true that the Linux kernel does not have video card support in it. That facility is provided by video drivers in other software; nearly all graphical software available for Linux uses X11 for access to those video drivers. Open-source X11 drivers for most video cards are available from www.xfree86.org; the list of supported cards there currently lists 555 different kinds of video cards, many of which include numerous individual models.

For those few cards for which XFree86 support is not available, proprietary X11 drivers are available from Xi Graphics and Metro-Link.

With XFree86, Linux's video card support is better than either Windows 98 or Windows NT, and considerably more extensive than any Unix that does not use XFree86.

To claim that Linux lacks video card support is merely laughable.

With regard to wireless LAN support, it is true that many of the recent wireless LAN products do not currently have support in Linux. However, Linux has had support for packet-radio wireless networking and several kinds of LANs for years, and has supported several wireless LAN products since at least late 1997, including most of the most popular ones:

Lucent Wavelan
DEC RoamAbout DS
Lucent Wavelan IEEE
Netwave Airsurfer
Xircom Netwave
Proxim RangeLan2
Proxim Symphony
DEC RoamAbout FH
Aironet ARLAN
Raytheon Raylink
BreezeCom BreezeNet

This information is readily available on the Web in the Linux Wireless LAN Howto.

With regard to productivity software, there are several office suites available for Linux, and there have been for several years. ApplixWare and StarOffice are the two most common.

With regard to the size of Linux: first, among the utilities tested in the failure-rate study (the latest report on which is entitled "Fuzz Revisited: A Re-examination of the Reliability of Unix Utilities and Services". the quote used on page 125 appears to be from the original paper, which I cannot find on the Web) are the standard set of Unix utilities, awk, grep, wc, and so forth. These utilities have a standard set of functionality common across all Unix systems, except that the GNU utilities tend to have a great deal of extra functionality included. If the GNU utilities really are only one-sixth the size of the corresponding utilities on a Unix system, yet provide much more functionality, and still have one-third to one-sixth of the failure rate, that is not an indictment of the defect rate of free software, but rather a vindication of it -- which is why this study is linked to from the Free Software Foundation's Web pages. The study is unfairly biased in favor of less-featureful proprietary software, and that software still came out way behind.

(From my own experience, I know that frequently, the best workaround for a bug in a Unix utility is to install the GNU version.)

Lewis's claim that this represents "a single-point estimate of defect rate" is incorrect. The paper includes detailed results of the tests on 82 different utilities, along with aggregate statistics by operating system. 63 of these utilities were available either from GNU or from Linux, and were tested in this study.

With regard to the lines-of-code figure: it is not easy to measure the number of lines of code that constitute "Linux", because it is not easy to define what constitutes "Linux" -- or, for that matter, "Unix" either.

If we mean just the kernel, this site has some figures for the sizes of several OS kernels in 1994. SunOS 5.2's kernel is listed as containing 680,000 lines of code, while SunOS 5.0's kernel is listed as containing 560,000 lines of code. If the rate of increase per version remained constant (doubtful, because 5.0 and 5.1 weren't really finished products) then the latest SunOS (the one that's the kernel of just-released Solaris 7) would contain 1,280,000 lines of code.

By comparison, the source code of the 2.2.1 Linux kernel totals 1,676,155 lines of code, including comments and blank lines, counting only .c, .h, and .S (assembly) files.

The Linux project's source code has already reached a level where we would "expect Linux defect densities to get worse". They haven't.

On page 125, Lewis cites Apache as an example of support diminishing when "the hype wears off", saying "it is currently supported by fewer than 20 core members" -- implying that the "cast of thousands" is a thing of the past. The truth is that the core Apache team has never been larger than 20 people, and they *still* receive contributions from many people outside the group. He also says that "Apache is losing the performance battle against Microsoft's IIS." But Apache has never been intended to be the fastest HTTP server around -- it's already more than fast enough to saturate a T1 when running on a puny machine, so its developers have been concentrating on things like adding more features and making it more reliable.

On page 128, Lewis says, "The concept of free software is a frequently practiced strategy of the weak". While free-as-in-price giveaways are common -- Microsoft's Internet Explorer strategy is a perfect example -- they are not related to open-source software, and their patterns of success and failure have little relevance for us here.

Kragen Sitaker has written a brutal reply to the story Sengan posted yesterday on the The Open Source Acid Test. It goes down and point by point shows the factual errors and fud in the story. It pleases me greatly to post this feature. Check it out. The following was written by Slashdot Reader Kragen Sitaker

I read Ted Lewis's article, _The Open Source Acid Test_, on your web pages.

I was appalled that an organ of a prestigious international society like the IEEE would publish such error-riddled, poorly-researched, deliberately deceptive nonsense. It's as if the _New England Journal of Medicine_ had published a case study of a zombie animated by voodoo!

The author did not cite sources for any of his dubious statistics, and they are therefore hard to disprove. Given the remarkable lack of factual accuracy in the article, I doubt that they have any basis in fact.

To begin with the most obvious errors:

1. Linus Torvalds's name is not Linus Torvold.
2. Applix, Tower Technology, and NewMonics do not sell open-source software.
3. There is no such company as "Walnut Creek Stackware". www.cdrom.com belongs to Walnut Creek CDROM. There is no such company as "Tower Tech JVM". www.twr.com belongs to Tower Technology, which sells a (non-open-source) JVM. There is no such web site as www.debian.com.
4. www.python.org is operated by the Python Software Association, not CNRI, although it is currently hosted on CNRI's network.
5. Several of the "commercial enterprises" listed in Table 1 are not commercial enterprises at all. www.hungry.com, www.python.org, and www.debian.org are all operated by nonprofit organizations. The Corporation for National Research Initiatives, which was incorrectly listed as operating www.python.org, is actually a not-for-profit research organization.
6. It is absurd to say that Unix was the foundation for Hewlett-Packard and IBM, as Lewis does in his introductory paragraph. Both companies had been established for more than thirty years when the first line of Unix was written.
7. On page 126, Lewis claims that the open-source community admits that its organizational structure is weak. The evidence he adduces is a quote from a document published on www.opensource.org. What he doesn't tell you is that the document is *a leaked internal Microsoft memo*. Unless Lewis missed the 115 references to Microsoft in this document and also failed to read the introductory paragraphs, the only reasonable conclusion is that he is being deliberately deceptive.
8. On page 125, Lewis claims that "Currently, Linux's installed base numbers 7.5 million". As usual, he cites no source. However, the most widely-cited source for such figures is Robert Young's paper, Sizing the Linux Market eight different data sources to obtain an estimate of between five and ten million Linux users. However, this paper has a date of March 1998. If Linux's growth had continued to double yearly in 1998, as it did from roughly 1993 to 1998, the number of Linux users would be between ten and twenty million.
9. On page 128, Lewis says, "Windows NT market share smothers all Unix dialects combined". According to International Data Corporation's Server Operating Environment report, Unix and Linux together had 34.6% of the server market in 1998, while Windows NT had 36%. See more information. The actual number of server Linux shipments IDC tallied in 1998 was only three-quarters of a million; that suggests that if you include people installing multiple servers from the same CD and installing from Internet downloads, you would find that Linux's server market share is much greater than Windows NT's.
10. Lewis remarks, "With few exceptions, open source software has never crossed the chasm into the mainstream without first becoming a commercial product sold by a commercial enterprise." Does he think that Linux is not a commercial product sold by commercial enterprises? If not, there are literally dozens of "exceptions" to this statement -- Perl, Apache, sendmail, BIND, Linux, Tcl/Tk, Berkeley DB, Samba, the X Window system, FORTH, GNU Emacs, and trn, for example. Many of these became popular before they were commercially sold at all.
11. Lewis misstates the business case for Linux and "its open source software cousins". According to Eric Raymond -- whom Lewis quotes extensively elsewhere in this article -- a much more compelling business case is founded on the better quality of the software, choice of suppliers, choice of support and maintenance, freedom from legal exposure and license tracking. More details are available at opensource.org/for-buyers.html.

These minor factual errors, so far, merely indicate that the author knows very little about the topic he writes about and is deliberately trying to mislead his readers; they do not directly undermine his conclusions. However, as I shall show, each of his supporting arguments consist of incorrect facts and lead to faulty conclusions.

One of the author's major contentions is that as Open Source software adds more features and becomes more comparable to proprietary software, it will lose many of its advantages. He cites as examples Linux's supposed lack of video card support, wireless LAN support, and "a good selection of productivity software."; he claims that Unix contains 10 million lines of code, while Linux contains only 1.5 million. On page 126, he says, "Maintenance and support grow more complex, and costs increase due to a scarcity of talented programmers. Success leads to features, and feature creep leads to bloated software."

With regard to video card support, it is true that the Linux kernel does not have video card support in it. That facility is provided by video drivers in other software; nearly all graphical software available for Linux uses X11 for access to those video drivers. Open-source X11 drivers for most video cards are available from www.xfree86.org; the list of supported cards there currently lists 555 different kinds of video cards, many of which include numerous individual models.

For those few cards for which XFree86 support is not available, proprietary X11 drivers are available from Xi Graphics and Metro-Link.

With XFree86, Linux's video card support is better than either Windows 98 or Windows NT, and considerably more extensive than any Unix that does not use XFree86.

To claim that Linux lacks video card support is merely laughable.

With regard to wireless LAN support, it is true that many of the recent wireless LAN products do not currently have support in Linux. However, Linux has had support for packet-radio wireless networking and several kinds of LANs for years, and has supported several wireless LAN products since at least late 1997, including most of the most popular ones:

Lucent Wavelan
DEC RoamAbout DS
Lucent Wavelan IEEE
Netwave Airsurfer
Xircom Netwave
Proxim RangeLan2
Proxim Symphony
DEC RoamAbout FH
Aironet ARLAN
Raytheon Raylink
BreezeCom BreezeNet

This information is readily available on the Web in the Linux Wireless LAN Howto.

With regard to productivity software, there are several office suites available for Linux, and there have been for several years. ApplixWare and StarOffice are the two most common.

With regard to the size of Linux: first, among the utilities tested in the failure-rate study (the latest report on which is entitled "Fuzz Revisited: A Re-examination of the Reliability of Unix Utilities and Services". the quote used on page 125 appears to be from the original paper, which I cannot find on the Web) are the standard set of Unix utilities, awk, grep, wc, and so forth. These utilities have a standard set of functionality common across all Unix systems, except that the GNU utilities tend to have a great deal of extra functionality included. If the GNU utilities really are only one-sixth the size of the corresponding utilities on a Unix system, yet provide much more functionality, and still have one-third to one-sixth of the failure rate, that is not an indictment of the defect rate of free software, but rather a vindication of it -- which is why this study is linked to from the Free Software Foundation's Web pages. The study is unfairly biased in favor of less-featureful proprietary software, and that software still came out way behind.

(From my own experience, I know that frequently, the best workaround for a bug in a Unix utility is to install the GNU version.)

Lewis's claim that this represents "a single-point estimate of defect rate" is incorrect. The paper includes detailed results of the tests on 82 different utilities, along with aggregate statistics by operating system. 63 of these utilities were available either from GNU or from Linux, and were tested in this study.

With regard to the lines-of-code figure: it is not easy to measure the number of lines of code that constitute "Linux", because it is not easy to define what constitutes "Linux" -- or, for that matter, "Unix" either.

If we mean just the kernel, this site has some figures for the sizes of several OS kernels in 1994. SunOS 5.2's kernel is listed as containing 680,000 lines of code, while SunOS 5.0's kernel is listed as containing 560,000 lines of code. If the rate of increase per version remained constant (doubtful, because 5.0 and 5.1 weren't really finished products) then the latest SunOS (the one that's the kernel of just-released Solaris 7) would contain 1,280,000 lines of code.

By comparison, the source code of the 2.2.1 Linux kernel totals 1,676,155 lines of code, including comments and blank lines, counting only .c, .h, and .S (assembly) files.

The Linux project's source code has already reached a level where we would "expect Linux defect densities to get worse". They haven't.

On page 125, Lewis cites Apache as an example of support diminishing when "the hype wears off", saying "it is currently supported by fewer than 20 core members" -- implying that the "cast of thousands" is a thing of the past. The truth is that the core Apache team has never been larger than 20 people, and they *still* receive contributions from many people outside the group. He also says that "Apache is losing the performance battle against Microsoft's IIS." But Apache has never been intended to be the fastest HTTP server around -- it's already more than fast enough to saturate a T1 when running on a puny machine, so its developers have been concentrating on things like adding more features and making it more reliable.

On page 128, Lewis says, "The concept of free software is a frequently practiced strategy of the weak". While free-as-in-price giveaways are common -- Microsoft's Internet Explorer strategy is a perfect example -- they are not related to open-source software, and their patterns of success and failure have little relevance for us here.

Nate writes "Ed Di Cristofaro of HardWire has announced he will extend his hardware testing to Linux along with the usual Windows testing. "It's quickly spreading in popularity and has the potential to fall right behind Windows and into the #2 spot for desktop operating system users." Click below to read on.

Martin Hepworth writes "Looks like SUN are bowing the M$'s 'user-friendly' installation with a deal with Install Shield Software. "

Johan Walles writes "I dunno whether "scoop" is the correct term for this, but anyway: slashdot.org is on tenth place of the site rankings for the "Computers/Internet" category on Sixdegrees link Forty more votes would put Slashdot on third place (before www.linux.org), and 170 votes would put it first (above www.icq.com and www.cnet.com). So if all sixdegrees users reading /. would go "slashdot-effect" the poll, a whole bunch of new readers might very well see the light and come to /. for their daily updates :-)."

James S. Baughn writes "Seeing as how there aren't any good Linux humor sites, I've created Humorix: "All Linux Humor. All Copied Mottos. All the Time."

Exile57 writes "The music industry is trying to end the proliferation of the pirate music scene. Apparently, bootleg CD's are a booming market in other countries. On top of the CD's being pressed illegally, the industry is also a bit miffed at the amount of pirate MP3 sites on the Internet. Here's the story as told by CNN."

Andrew Dalke writes "Python 1.0 was just released It is an implementation of Python (my favorite language :) for the Java virtual machine. With it you get the full power of a very high level dynamic language able to access all of the Java classes, including awt, java beans, swing, jdbc and corba. It includes a binary version of OROMatcher to implement perl5 style regular expressions. I worked with the most recent beta version and didn't come across any bugs. The only problem I had was the startup time, which was about two seconds on my Indigo2 compared to the fraction of a second for the C implementation, but much of that was the JVM starting up. We also needed to sidegrade to Netscape's 4.05 AWT 1.1 Preview release to develop applets. The biggest advantage was the interactive nature of the implementation where I could test new code or examine the behaviour of different Java classes without recompiling. Overall I estimate that it took me about a quarter of the time to implement my project in JPython instead of straight Java. *advocacy on* I can predict people will comment on two things about Python as a language, so let me preemptively address them here: 1) Python isn't as flexible as Perl -- sure, but it is a lot cleaner in general and easier to do OO programming. I rarely notice the lack of the more baroque Perl control features since Python's exception handling and ease of creating helper classes simplify tasks like finalizing resource handling during error conditions. Python's real flexibility is integrating new functionality like Java classes, COM objects or database support in a straight-forward, modular fashion. More to the point of this announcement, you can't get a Perl applet running on top of the JVM. 2) Python uses indentation and newlines for scoping and statement end instead of {} and ; -- most people find it enjoyable once they get used to it (and when using an editor like emacs that understands the language syntax). It is a suprisingly nice feeling to be several blocks in at the end of a function definition and only having to press 'enter' to finish instead of ';enter}enter}enter}' to fulfil the requirements of the parser. *advocacy off* "

Robert Macaulay writes "There is a new CScene up: Issue 5"

Nate writes "Ed Di Cristofaro of HardWire has announced he will extend his hardware testing to Linux along with the usual Windows testing. "It's quickly spreading in popularity and has the potential to fall right behind Windows and into the #2 spot for desktop operating system users." Click below to read on.

Martin Hepworth writes "Looks like SUN are bowing the M$'s 'user-friendly' installation with a deal with Install Shield Software. "

Johan Walles writes "I dunno whether "scoop" is the correct term for this, but anyway: slashdot.org is on tenth place of the site rankings for the "Computers/Internet" category on Sixdegrees link Forty more votes would put Slashdot on third place (before www.linux.org), and 170 votes would put it first (above www.icq.com and www.cnet.com). So if all sixdegrees users reading /. would go "slashdot-effect" the poll, a whole bunch of new readers might very well see the light and come to /. for their daily updates :-)."

James S. Baughn writes "Seeing as how there aren't any good Linux humor sites, I've created Humorix: "All Linux Humor. All Copied Mottos. All the Time."

Exile57 writes "The music industry is trying to end the proliferation of the pirate music scene. Apparently, bootleg CD's are a booming market in other countries. On top of the CD's being pressed illegally, the industry is also a bit miffed at the amount of pirate MP3 sites on the Internet. Here's the story as told by CNN."

Andrew Dalke writes "Python 1.0 was just released It is an implementation of Python (my favorite language :) for the Java virtual machine. With it you get the full power of a very high level dynamic language able to access all of the Java classes, including awt, java beans, swing, jdbc and corba. It includes a binary version of OROMatcher to implement perl5 style regular expressions. I worked with the most recent beta version and didn't come across any bugs. The only problem I had was the startup time, which was about two seconds on my Indigo2 compared to the fraction of a second for the C implementation, but much of that was the JVM starting up. We also needed to sidegrade to Netscape's 4.05 AWT 1.1 Preview release to develop applets. The biggest advantage was the interactive nature of the implementation where I could test new code or examine the behaviour of different Java classes without recompiling. Overall I estimate that it took me about a quarter of the time to implement my project in JPython instead of straight Java. *advocacy on* I can predict people will comment on two things about Python as a language, so let me preemptively address them here: 1) Python isn't as flexible as Perl -- sure, but it is a lot cleaner in general and easier to do OO programming. I rarely notice the lack of the more baroque Perl control features since Python's exception handling and ease of creating helper classes simplify tasks like finalizing resource handling during error conditions. Python's real flexibility is integrating new functionality like Java classes, COM objects or database support in a straight-forward, modular fashion. More to the point of this announcement, you can't get a Perl applet running on top of the JVM. 2) Python uses indentation and newlines for scoping and statement end instead of {} and ; -- most people find it enjoyable once they get used to it (and when using an editor like emacs that understands the language syntax). It is a suprisingly nice feeling to be several blocks in at the end of a function definition and only having to press 'enter' to finish instead of ';enter}enter}enter}' to fulfil the requirements of the parser. *advocacy off* "

Robert Macaulay writes "There is a new CScene up: Issue 5"