Guido van Rossum Unleashed

Here you go - answers to your questions for Guido van Rossum about Python, its future, licensing hassles with the Free Software Foundation, and other neat stuff. Thanks, Guido!

Ruby
by Luke
Thoughts on Ruby?

Guido:
I just looked it up -- I've never used it. Like Parrot, it looks like a mixture of Python and Perl to me. That was fun as an April Fool's joke, but doesn't tickle my language sensibilities the right way.

That said, I'm sure it's cool. I hear it's very popular in Japan. I'm not worried.

Data Structures Library
by GrEp
I love python for making quick hacks, but the one thing that I haven't seen is a comprehensive data structures library. Is their one in development that you would like to comment about or point us to?

Guido:
One of Python's qualities is that you don't need a large data structures library. Rather than providing the equivalent of a 256-part wrench set, with a data type highly tuned for each different use, Python has a few super-tools that can be used efficiently almost everywhere, and without much training in tool selection. Sure, for the trained professional it may be a pain not to have singly- and doubly-linked lists, binary trees, and so on, but for most folks, dicts and lists just about cover it, and even inexperienced programmers rarely make the wrong choice between those two.

Since this is of course a simplification, I expect that we will gradually migrate towards a richer set of data types. For example, there's a proposal for a set type (initially to be added as a module, later as a built-in type) floating. See http://lists.sourceforge.net/lists/listinfo/python-sets and http://python.sourceforge.net/peps/pep-0218.html.

[j | c]Python
by seanw
How do you see the relationship between jPython (the java implementation) and standard cPython (the original C language version) evolving? And do you see the advantages of either one (i.e. portability vs. speed) becoming especially pronounced in light of the recent trend toward distributed software (ala the MS .NET initiative)?

Guido:
Note that the new name is Jython, by the way. Check out www.jython.org -- they're already working on a 2.1 compatible release.

We used to work really close -- originally, when JPytnon was developed at CNRI by Jim Hugunin, Jim & I would have long discussions about how to implement the correct language semantics in Java. When Barry Warsaw took over, it was pretty much the same. Now that it's Finn Bock and Samuele Pedroni in Europe, we don't have the convenience of a shared whiteboard any more, but they are on the Python developers mailing list and we both aim to make it possible for Jython to be as close to Python in language semantics as possible. For example, one of my reasons against adding Scheme-style continuations to the language (this has seriously been proposed by the Stackless folks) is that it can't be implemented in a JVM. I find the existence of Jython very useful because it reminds me to think in terms of more abstract language semantics, not just implementation details.

IMO the portability of C Python is better than that of Jython, by the way. True, you have to compile C Python for each architecture, but there are fewer platforms without a C compiler than platforms without a decent JVM.

Jython is mostly useful for people who have already chosen the Java platform (or who have no choice because of company policy or simply what the competition does). In that world, it is the scripting and extension language of choice.

does Python need a CPAN?
by po_boy
One of the reasons I still write some things in PERL is because I know that I can find and install about a zillion modules quickly and easily through the CPAN repository and CPAN module. I'm pretty sure that if Python had something similar, like the Vaults of Parnassus but more evolved that I would abandon PERL almost entirely.

Do you see things in a similar way? If so, why has Python not evolved something similar or better, and what can I do to help it along in this realm?

Guido:
It's coming! Check out the action in the catalog-sig http://python.org/sigs/catalog-sig/. You can help by joining.

One reason why it hasn't happened already is that first we needed to have a good package installation story. With the widespread adoption of distutils, this is taken care of, and I foresee a bright future for the catalog activities.

Favourite Python sketch?
by abischof
Considering that you named the language after the comedy troupe, what's your favourite Monty Python sketch? Personally, my favourite is the lecture on sheep aircraft, but I suppose that's a discussion for another time ;).

Guido:
I'm a bit tired of them actually. I guess I've been overexposed. :-)

Conflict with GPL
by MAXOMENOS
The Free Software foundation mentions the license that comes with Python versions 1.6b1 and later as being incompatible with the GPL. In particular they have this to say about it:

This is a free software license but is incompatible with the GNU GPL. The primary incompatibility is that this Python license is governed by the laws of the "State" of Virginia in the USA, and the GPL does not permit this.

So, my question is a two parter:

1.What was your motivation for saying that Python's license is governed by the laws of Virginia?

2.Is it possible that a future Python license could be GPL-compatible again?

Guido:
Let me answer the second part first. I asked the FSF to make a clear statement about the GPL compatibility of the Python 2.1, and their lawyer gave me a very longwinded hairsplitting answer that said neither yes nor no. You can read for yourself at http://www.python.org/2.1/fsf.html. I find this is very disappointing; I had thought that with the 1.6.1 release we had most of this behind us, but apparently they change their position at each step in the negotiations.

I don't personally care any more whether Python will ever be GPL-compatible -- I'm just trying to do the FSF a favor because they like to use Python. With all the grief they're giving me, I wonder why I should be bothered any more.

As for the second part: most of you should probably skip right to the next question -- this answer is full of legal technicalities. I've spent waaaaaaaaay to much time talking and listening to lawyers in the past year! :-(

Anyway. The Python 1.6 license was written by CNRI, my employer until May 2000, where I did a lot of work on Python. (Before that, of course, I worked at CWI in Amsterdam, whom I have to thank for making my early work on Python possible.) CNRI own the rights to Python versions 1.3 through 1.6, so they have every right to pick the license.

CNRI's lawyers designed the license with two goals in mind:(1) maximal protection of CNRI, (2) open source. (If (2) hadn't been a prerequisite for my employment at CNRI, they would have preferred not to release Python at all. :-)

Almost every feature of the license works towards protecting CNRI against possible lawsuits from disappointed Python users (as if there would be any :-), and the state of Virginia clause is no exception. CNRI's lawyers believe that sections 4 and 5 of the license (the all caps warnings disclaiming all warranties) only provide adequate protection against lawsuits when a specific state is mentioned whose laws and courts honor general disclaimers. There are some states where consumer protection laws make general disclaimers illegal, so without the state of Virginia clause, they fear that CNRI could still be sued in such a state. (Being a consumer myself, I'm generally in favor of such consumer protection laws, but for open source software that is downloadable for free, I agree with CNRI that without a general disclaimer the author of the software is at risk. I'm happy that Maryland, for example, is considering to pass a law that makes a special exception for open source software here.)

Python 1.6.1, the second "contractual obligation release" (1.6 was the first), was released especially to change CNRI's license in a way that resolved all but one of the GPL incompatibilities in the 1.6 license. I'm not going to explain what those incompatibilities were, or how they were resolved. Just look for yourself by following the "accept license" link at http://www.python.org/1.6.1/. The relevant changes are all in section 7 of the license, which now contains several excruciating sentences crafted to disable certain other clauses of the license under certain conditions involving the GPL. Read it and weep.

The remaining incompatibility, according to the FSF, is the "click-to-accept" feature of the license. This is another feature to protect CNRI -- their lawyers believe that this is necessary to make the license a binding agreement between the user and CNRI. The FSF is dead against this, and their current position is that because the GPL does not require such an "acceptance ceremony" (their words), any license that does is incompatible with the GPL. It's like the old story of the irresistible force meeting the immovable object: CNRI's lawyers have carefully read the GPL and claim that CNRI's license is fully compatible with the GPL, so you can take your pick as to which lawyer you believe.

Anyway, I removed the acceptance ceremony from the 2.1 license, in the hope that this would satisfy the FSF. Unfortunately, the FSF's response to the 2.1 license (see above) seems to suggest that they have changed their position once again, and are now requesting other changes in the license. I'm very, very tired of this, so on to the next question!

Structured Design.
by Xerithane
First off, as a disclaimer I have never actually written anything in Python. But, I have read up on virtually all the introduction articles and tutorials so I have a grasp on syntax and structure.

I have been doing C development for 9 years now, and I know a plethora of other languages including shell scripting, perl, PHP (for scripts). Now, each language uses 'normal' grouping for control structures (if, for, etc).

What was the logic behind creating a whitespace-based syntax rule? And why do you feel it is good, please refrain from the readability answer because that is all I get from those people I know who know Python.

I find, because of my background, it is much easier to read code that uses braces ({}) than whitespace because my mind automatically looks for them. After maintaining legacy code that extends a life span of 20 years from it's first line of code, I have some concerns about the longevity of any Python code. So, my second question is, how well do you see Python holding up for 20 years and why do you think it will hold up that long?

Guido:
What's wrong with the legibility answer? I think that's an *excellent* reason! Don't care if your code is legible?

Don't you hate code that's not properly indented? Making it part of the syntax guarantees that all code is properly indented!

When you use braces, there are several different styles of brace placement (e.g. whether the open brace sits on the same line as the "if" or on the next, and if on the next, whether it is indented or not; ditto for the close brace). If you're used to code written in one style, it can be difficult to read code written in another. Most people, when skimming code, look for the indentation anyway. This leads to sometimes easily overlooked bugs like this one:

  if (x  10)
      x = 10;
      y = 0;

Still not convinced? In 1974, Don Knuth predicted that indentation would eventually become a viable means of structuring code, once program units were small enough. (Full quotation: http://www.amk.ca/quotations/python-quotes/page-1.html)

Still not convinced? You admit that you haven't tried it yet. Almost everybody who tries it gets used to it very quickly and end up loving the indentation feature, even those who hated it at first. There's still hope for you!

So, no, I'm not worried about Python holding out 20 more years.

What is *your* idea of Python and its future?
by Scarblac
There are a lot of "golden Python rules" or whatever you would call them, like "explicit is better than implicit", "there should be only one way to do it", that sort of thing. As far as I know, those are from old posts to the mailing list, often by Tim Peters, and they've become The Law afterwards. In the great tradition of Usenet advocacy, people who suggest things that go against these rules are criticized. But looking at Python, I see a lot more pragmatism, not rigid rules. What do you think of those "golden rules" as they're written down?

What's your idea of the future of Python? Since the PEP process, a lot of new feature ideas have been put forward, and a lot of people feel uncomfortable with quick change to a good language (Python 2.1 is again excellent though, congrats). Do you think or hope Python will be finished one day? If not, isn't the alternative an endless string of added features? "Python 3000" was an idea of a sort of ideal Python that would be worked on, but as I understand Python will now evolve more gradually.

Guido:
You're referring to the "Zen of Python", by Tim Peters: http://www.python.org/doc/Humor.html#zen

It's no coincidence that these rules are posted on the Python Humor page!

Those rules are useful when they work, but several of the rules warn against zealous application (e.g. "practicality beats purity" and and "now is better than never").

While we put "There's only one way to do it" on a T-shirt, mostly to poke fun at Larry Wall's TMTOWTDI, the actual Python Zen rule reads: "There should be one-- and preferably only one -- obvious way to do it." That has several nuances!

Regarding the future, I doubt that any piece of software ever stops evolving until it dies. It's like your brain: you never stop learning. Good software has the ability to evolve built in from the start, and evolves in a way that keeps the complexity manageable.

Python started out pretty well equipped for evolution: it was extensible at two levels (C extension modules and Python modules) that didn't require changing the language itself. We've occasionally added features to support evolution better, e.g. package namespaces make it possible to have a much large number of modules in the library, and distutils makes it easier to add third party packages.

I hear the complaints from the community about the rate of change in Python, and I'm going to be careful not to change the language too fast. The next batch of changes may well be aimed at *reducing* complexity. For example, there are PEPs proposing a simplification of Python's numeric system (like eradicating the distinction between 32/64-bit ints and bignums), and I've started to think seriously about removing the distinction between types and classes -- another simplification of the language's semantics.

Strangest use of Python
by Salamander
What use of Python have you found that surprised you the most, that gave you the strongest "I can't believe they did that" reaction?

Guido:
I find few things strange.

For the most obfuscated code I've ever come across, see the Mandelbrot set as a lambda, http://www.python.org/doc/FAQ.html#4.15.

Digital Creations has written a high-performance fully transactional replicated object database in Python. That's definitely *way* beyond what I thought Python would be good for when I started.

Some people at national physics labs like LANL and LLNL have a version of Python running on parallel supercomputers with many hundreds of processors. That's pretty awesome.

But my *favorite* use of Python is at a teaching language, to teach the principles of programming, without fuss. Think about it -- it's the next generation!

--Guido van Rossum (home page: www.python.org/~guido)

Comments

Re:Braces vs Whitespace

[cduffy]

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

Not even once.

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

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

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

Re:Braces vs Whitespace

[cduffy]

If you equate productivity with the end-of-block character choice, you've got one helluva messed up concept of programming.

Python makes me fast not only because of its syntax, but also (and perhaps more importantly) its built-in data types, its weak typing system, and other behind-the-scenes work.

Frankly, I'm inclined to call your post a troll.

Braces vs Whitespace

[Tony]

Excellent answers.

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

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

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

Re:Braces vs Whitespace

[Ian Bicking]

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

Re:Braces vs Whitespace

[ptomblin]

I have two problems with whitespace indentation:

• No common text editor has a decent "go to the end of the block" function. They all have "go to the matching brace", though.
  
• What happens when you have a line with 8 spaces followed by a line with a tab? I haven't used python, but one language I used that used whitespace indentation treated them differently, so you had lines that looked like they were indented the same, but the interpreter didn't think they were. Add in complications with people who have set their tab stops differently from you, and you might as well give up right now.
  

Re:Braces vs Whitespace

[ptomblin]

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

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

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

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

Re:Braces vs Whitespace

[William Tanksley]

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

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

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

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

-Billy

Re:Braces vs Whitespace

[William Tanksley]

Keep in mind that Python's indentation/blocking rules are _totally_ different from MUMPS'. They don't have the same problems or benefits.

-Billy

Re:Braces vs Whitespace

[William Tanksley]

Good concerns.

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

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

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

Hope that helps.

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

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

-Billy

Re:Braces vs Whitespace

[Zagadka]

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

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

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

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

Re:Braces vs Whitespace

[david.given]

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

Remember the Golden Rule of Programming:

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

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

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

Re:Braces vs Whitespace

[Dr.Dubious DDQ]

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

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

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

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

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

---

Re:Braces vs Whitespace

[elmegil]

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

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

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

Re:Braces vs Whitespace

[elmegil]

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.

Re:Braces vs Whitespace

[Sloppy]

I like my code to fit my style.

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

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

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

---

Re:Braces vs Whitespace

[magic]

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

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

-m

Re:Braces vs Whitespace

[pthisis]

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

Try this.

from sys import*;from string import*;a=argv;[s,p,q]=filter(lambda x:x[:1]!=
'-',a);d='-d'in a;e,n=atol(p,16),atol(q,16);l=(len(q)+1)/2;o,inb=l -d,l-1+d
while s:s=stdin.read(inb);s and map(stdout.write,map(lambda i,b=pow(reduce(
lambda x,y:(x>8*i&255),range(o-1,-1,-1)))

It's Andrew Kutchlings, from http://www.cypherspace.org/~adam/rsa/python.html

Sumner

Re:Braces vs Whitespace

[Russ Nelson]

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

Re:Braces vs Whitespace

[segmond]

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

Re:Braces vs Whitespace

[1010011010]

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

Vi doesn't. But I only use vi when I have to. I never want to.

- - - - -

Re:Braces vs Whitespace

[1010011010]

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

Thanks! I appreciate the help.

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

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

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

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

- - - - -

Re:Braces vs Whitespace

[bnenning]

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

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

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

Re:Braces vs Whitespace

[Doc Hopper]

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

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

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

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

Matt Barnson

Re:Braces vs Whitespace

[Ramses0]

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

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

--Robert

Re:Braces vs Whitespace

[Fencepost]

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

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

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

-- fencepost

Re:Braces vs Whitespace

[connorbd]

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

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

/Brian

Re:Braces vs Whitespace

[keesh]

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

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

Re:Braces vs Whitespace

[keesh]

Lots of work though, and a waste of a special character... Yeah, OK, I use Perl, I like character soup :)

Re:Braces vs Whitespace

[quantum bit]

In the immortal words of an Anonymous Coward: "Emacs is a nice OS - but it lacks a good text editor. That's why I am using Vim."

Re:Braces vs Whitespace

[Tech187]

Modularity is one of the strong features of Python. Perhaps that reinforces the relevance Knuth's quote.

Re:Braces vs Whitespace

[Tech187]

Hmmm,

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

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

Re:YADNAL

[X]

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

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

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

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

Re:Licence issues

[Jason Earl]

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

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

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

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

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

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

Argh. We need license compatibility.

[Zooko]

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

Re:Argh. We need license compatibility.

[AMK]

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

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

Python is why I chose not to GPL my DNS server

[Kiwi]

Anyway, I removed the acceptance ceremony from the 2.1 license, in the hope that this would satisfy the FSF. Unfortunately, the FSF's response to the 2.1 license (see above) seems to suggest that they have changed their position once again, and are now requesting other changes in the license. I'm very, very tired of this, so on to the next question!

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

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

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

- Sam

Re:Python is why I chose not to GPL my DNS server

[MAXOMENOS]

That depends on which version of the Python language you use. Python 1.5.2 is fully GPL-compatible; Python 2.1 isn't. If you're worried about GPL compatibility, stick with 1.5.2.

ObJectBridge (GPL'd Java ODMG) needs volunteers.

Re:Argh. We need license compatibility.

[DLPierson]

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

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

Re:the GPL is not a contract

[sethg]

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

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

the GPL is not a contract

[sethg]

License == Contract

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

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

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

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

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

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

Re:the GPL is not a contract

[ryants]

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

That sounds like a contract to me.

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

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

Ryan T. Sammartino

Re:the GPL is not a contract

[ryants]

However, the law has a more stringent definition of "contract".

Yeah... that's why the definition I posted has (Law) in front of it, which means "not the informal definition, but rather the jargon of a certain profession".

Ryan T. Sammartino

Re:Indentation syntax has its problems too

[ChadN]

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

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

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

Re:To all you whiners

[irix]

Yeah, and C supports indentation delimiting too:

if(a==b)
{
/* ignore previous line please */
a = c;

...

That's where code formatters come into play...

[SuperKendall]

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

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

Sick of Perl/perl/PERL bigots..

[musicmaker]

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

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

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

Re:Licence issues

[Russ Nelson]

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

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

Re:Easily overlooked - not.

[Russ Nelson]

There's an < missing between x and 10. That's what your C parser is picking up on.
-russ

No. There is no opportunity for acceptance or rej

[Russ Nelson]

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

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

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

Re:YADNAL

[Russ Nelson]

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

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

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

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

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

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

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

Re:YADNAL

[Russ Nelson]

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

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

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

Re:Huh?

[Russ Nelson]

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

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

GPL is fundamentally broken, sorry.

[Russ Nelson]

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

The GPL warranty disclaimer can't work.
-russ

Re:GPL is fundamentally broken, sorry.

[ryants]

But the GPL is explicitly not a contract, but is instead a set of copyright permissions.

Er... the GPL is a License (the "L" in GPL)...

License == Contract ... it is the terms under which you can use/copy/modify GPLed software.

Ryan T. Sammartino

Re:Problem with Python...

[segmond]

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

Indentation syntax has its problems too

[nevets]

What's wrong with the legibility answer? I think that's an *excellent* reason! Don't care if your code is legible?

In other words: "NO, I don't have another answer".

Sorry, but I also don't care for the indentation for the exact reason that he gives.

if (x == 4)
x = 10;
y = 6;

Now how did I know that the writers intent was

if (x == 4) { x = 10; }
y = 6;

or

if (x == 4) {
x = 10; y = 6;
}

the if without braces should also be avoided in C but I do fall for that too.

Now if you use the braces, you know what the programmers intent was. But with Python, you don't. It could have been an indentation mistake, and that is harder to debug.

So if they ment
if (x == 4) { x = 10;}
y = 6;
How will you know with just an indentation syntex.

I used Python for about a month, and gave up and went back to Perl for scripting. This is probably because of my long C experience.

I believe in the More than one way of doing it. That's also probably why I hate MS Windows!

Steven Rostedt

Re:Indentation syntax has its problems too

[gargle]

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

Re:Indentation syntax has its problems too

[wrygrin]

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

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

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

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

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

R and Python

[hopeless case]

Damn, I wish I'd seen the original request for questions.

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

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

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

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

Re:"State" of Virginia?

[1010011010]

http://www.dictionary.com/cgi-bin/dict.pl?term=com monwealth

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

- - - - -

Re:Argh. We need license compatibility.

[runswithd6s]

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

From the DFSG:

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

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

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

So, start packaging!

--

Re:Hrmph!

[jacobm]

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

--
-jacob

Hrmph!

[jacobm]

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

Get over it!

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

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

--
-jacob

FSF cares but goes too far

[Christianfreak]

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

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

"One World, one Web, one Program" - Microsoft promotional ad

Re:FSF cares but goes too far

[The Pim]

I think we all want the same thing, which is choice in the marketplace and real compitition.

Go read gnu.org. That's not what they want at all. Maybe when you realize what they want, what they do won't seem so strange.

Re:Whitespace and Python as a Teaching Tool

[smack.addict]

I think I would expect more insightful commentaries from someone that has written books published by Oreilly than "No way in hell you can do that with Perl where you have to be an expert in order to read other people's code.".

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

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

Whitespace and Python as a Teaching Tool

[smack.addict]

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

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

On Python for Teaching
Guido stated:
But my *favorite* use of Python is at a teaching language, to teach the principles of programming, without fuss. Think about it -- it's the next generation!

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

Quibbles about the 2.1 Lic.

[jallen02]

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

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

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

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

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

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

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

Jeremy

Re:Argh. We need license compatibility.

[RevAaron]

Before this get's labeled a troll...

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

The FSF has some good points

[legLess]

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

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

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

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

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

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

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

Re:The FSF has some good points

[warmiak]

"The bottom line is that the GPL is the most powerful defense that Free software has"

So much freedom that it takes a lawyer to figure it out.
Thanks, I will stick to BSD-style, no strings attached, real freedom license.

Frustrated with this interview

[kalifa]

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

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

Re:Guido van Rossum Unleashed?

[TeknoHog]

Guido van Rossum in a Nutshell

How about the following for Linux hackers:

Kernel in a Nutshell

or any other *shell for that matter. Which reminds /me of the phrase ``She sells C shells down the C source.''

--

It's hard to beat The Cheese Shoppe ....

[Curious__George]

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

Curious George

"State" of Virginia?

[sulli]

Well, Virginia is a Commonwealth, as any Virginian knows, so that might be part of the problem!

The easiest way to GPL compatibility

[RedLaggedTeut]

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

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

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

Apologies for attaching to the top rated post - I'm not a pilotfish.

Guido van Rossum Unleashed?

[Slashdot Cruiser]

May I assume that the following books will also be available soon?

Instant Guido van Rossum
Mastering Guido van Rossum
Guido van Rossum for Dummies
Learn Guido van Rossum in 24 Hours
Guido van Rossum in a Nutshell

Parrot for Dummies

[Anonymous Cowturd]

I recently bought a 'Parrot for Dummies' Book, but simply do not understand it. Does anyone want to take it off my hands? I'll sell it to whoever makes the best offer.





if 'fruits de mer' = seafood

Re:Too bad, he "skipped" the comparison with Ruby.

[MeowMeow Jones]

Although he did say that he was considering abolishing the differnce between types and classes, which seems to be the biggest gripe Ruby people have against the 'oo purity' of python.

Trolls throughout history:

Problem with Python...

[MadCow42]

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

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

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

Oh well...

Freeze-a-phobically-yours, Madcow.

Re:use vs. copying

[ryants]

Sure... fair enough.

That doesn't change the fact that it is a contract.

Ryan T. Sammartino

no answers on efficient compilation

[janpod66]

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

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

Re:Unfavorable View of the FSF?

[janpod66]

But instead, he insulted TrollTech and KDE yet again,

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

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

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

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

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