Slashdot Mirror
Guido van Rossum Unleashed
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)
Guido:
Please take a deep breath and go in for one last go-around with the FSF lawyers. Pretty please?
As far as I could tell, the remaining issues are just "legalese exhaustion" on your part rather than actual conflicting goals. Maybe you could deputize a legalese wrangler to finish negotiations for you, or you could take a month-long break in which you never think a single thought about licenses, and then you go back and finish the negotiations.
This is really important to me, although I am not a GPL fanatic, because if it remains the case that the licenses are (allegedly) incompatible, then there will be lots and lots of people who will refuse to combine GPL code with Python, and that would really suck.
For example, I want to package up my open source application Python, Mojo Nation to be included in Debian. This would be a way to reach hundreds of thousands (? maybe fewer. Anyone know how many Debian users there are out there?) of highly clueful users and hackers who would otherwise never install Mojo Nation. The Mojo Nation code source code itself is under the LGPL, and some of the open source libraries that it uses are other under free licenses. Would this cause a legal conflict that would force the debian people to keep it off of their servers? I don't know (since it is LGPL instead of GPL), but I would feel so much better if the Python license were officially GPL compatible.
Regards,
Zooko
Let me point out that the GPL-compatibility doesn't affect software written in Python, only attempts to embed the Python interpreter inside a GPLed program. For example, there's GPLed software written in Java, even though the most commonly used JVM isn't GPLed. Python's license should be irrelevant to whatever license your Python application uses.
Also, note that the Apache license isn't GPL-compatible, yet that doesn't prevent Debian including Apache. I view this debate as a tempest in a teapot; it may affect people who want to do things like embed Python inside the GIMP, say, but most Python users don't have to care.
The bottom line: my vi editor, and I'm sure someone else's EMACS editor, allow me to match braces with a keystroke. While there may be some way to program EMACS to do the same for white space delimitations, I can't imagine finding a way to do that in vi. Considering which of these is the "standard" Unix editor, that seems like a big flaw.
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
The GPL includes a warranty disclaimer. A warranty disclaimer is part of contract law. But the GPL is explicitly not a contract, but is instead a set of copyright permissions. So the warranty disclaimer doesn't apply to anyone who doesn't copy code.
The GPL warranty disclaimer can't work.
-russ
Don't piss off The Angry Economist
I have to underline Guido's side remark about the person who asked about whitespace not having used Python before. When I first encountered Python, I thought the idea of syntactically meaningful whitespace was absurd. Then I realized that I, as a novice with very little understanding of Python, could read some of the most complex code from expert Python coders. No way in hell you can do that with Perl where you have to be an expert in order to read other people's code. This syntactic whitespace remains useful even when you become an expert, especially and expert who has to deal with novices daily.
Unless your code is for you and only you, readability is perhaps the single most important feature of your code.
On Python for Teaching
Guido stated:
But my *favorite* use of Python is at a teaching language, to teach the principles of programming, without fuss. Think about it -- it's the next generation!
In a similar vein, I also use Python as a whiteboard language even though I do most of my programming in Java. Specifically, Python let's you write out valid programming logic that reads like English. The result is that by thinking on the whiteboard in Python and then translating into Java, I end up with sounder programming logic.