Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Guido van Rossum Unleashed

Roblimo posted more than 13 years ago | from the burned-out-on-monty dept.

Programming 241

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)

Sorry! There are no comments related to the filter you selected.

Re:Indentation syntax has its problems too (1)

Anonymous Coward | more than 13 years ago | (#276756)

"How will you know with just an indentation syntex. " [sic]

Well, since indentation level dictates grouping

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

must be:

if x == 4:
x = 10
y = 6

whereas

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

must be

if x == 4:
x = 10
y = 6

I'm sorry, but to me it's as clear as day and completely unambiguous. You seem to have missed the point - that indentation level expresses the intent.

Ruby (1)

Anonymous Coward | more than 13 years ago | (#276757)

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

and it prints: 1
2
3
4

To iterate through a hash in Ruby, you do:

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

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

Defining a class is straightforward:
class MyClass
@@numInst #class vars start with '@@'
attr_accessor :x,:y,:z,:numInst
def initialize(x,y,z="something")
#constructor, gets called by 'new' #note: instance vars start with '@'
@x = x
@y = y
@z = z
@@numInst += 1
end
end

inst1 = MyClass.new(1,2)
puts "x = " inst2 = MyClass.new(3,4,"something else")
puts "total number of instances"
Note: the attr_accessor method above creates accessor methods for the variables in the list following it
Anyway, Ruby is very cool check it out at:
http://www.ruby-lang.org
or:
http://www.rubycentral.com

Re:Braces vs Whitespace (1)

Tony (765) | more than 13 years ago | (#276766)

You *like* Mumps?

Good God, no! I just have to program in it. Occassionally.

One of MUMPS' problems is the blocking via indentation. It got so bad, they added the "." for explicit blocking-- as in:

I $L(NDC)=11 D Q
.S X=$$FINDNDC(NDC)
.I X D
..N F S F=$P(^APSAMDF(X,2),"^",3)
..W:OUTPUT $$FMTNDC(NDC,5,4,2)," Format=",F,!
.E W NDC," Not found",!
W:OUTPUT "Test ",NDC,"..."

You are right-- it's a holy war issue. My experience with indentation-as-blocking has not been good; doesn't mean it doesn't work for other people. Python is a great language... for other people.

Re:Braces vs Whitespace (1)

Tony (765) | more than 13 years ago | (#276767)

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

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

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

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

Braces vs Whitespace (2)

Tony (765) | more than 13 years ago | (#276768)

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 (2)

ptomblin (1378) | more than 13 years ago | (#276773)

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 (2)

ptomblin (1378) | more than 13 years ago | (#276774)

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 (1)

Christopher Craig (1394) | more than 13 years ago | (#276775)

Ed is the standard Unix Editor

To all you whiners (1)

Christopher Craig (1394) | more than 13 years ago | (#276776)

As any serious Python programmer knows, Python already supports block delimiting. For instance the statement:

if (a==b):
#begin
x=2;
y=3;
#end

is correct, as is

if (a==b):
#{
x=2;
y=3;
#}
print x;

This is all explained in the Python documentation [python.org] for those of you who have not seen this before.

Re:Braces vs Whitespace (3)

William Tanksley (1752) | more than 13 years ago | (#276779)

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:Licence issues (2)

Jason Earl (1894) | more than 13 years ago | (#276780)

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

Zooko (2210) | more than 13 years ago | (#276782)

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 [mojonation.net] to be included in Debian. This would be a way to reach hundreds of thousands (? maybe fewer. Anyone know how many Debian users there are out there?) of highly clueful users and hackers who would otherwise never install Mojo Nation. The Mojo Nation code source code itself is under the LGPL, and some of the open source libraries that it uses are other under free licenses. Would this cause a legal conflict that would force the debian people to keep it off of their servers? I don't know (since it is LGPL instead of GPL), but I would feel so much better if the Python license were officially GPL compatible.

Regards,

Zooko

Python is why I chose not to GPL my DNS server (2)

Kiwi (5214) | more than 13 years ago | (#276786)

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

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

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

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

- Sam

Re:Braces vs Whitespace (2)

david.given (6740) | more than 13 years ago | (#276790)

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:Argh. We need license compatibility. (3)

DLPierson (8772) | more than 13 years ago | (#276791)

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:Easily overlooked - not. (1)

Tripp Lilley (8787) | more than 13 years ago | (#276792)

It's perfectly valid. It may even be perfectly correct, but the indentation suggests an intent that the code does support.

Yes, it is "suspicious", inasmuch as one would probably never write this code all at once. However, programmers, practicing the First Virtue (laziness), very often use:

if (x > 10) x = 10;

or the original, indented example, leaving out the braces in either case. When another coder comes along and realizes that the code also needs to set y=0 when x > 10, there is a "not insignificant" chance that they will forget to wrap the whole thing in braces.

The reason for this is simple: tunnel vision. It's the same thing that causes me to make a perfect cut on my tablesaw, then perfectly align the perfectly-cut piece with the wrong side of the other perfectly-cut piece, and glue them together.

In this particular regard, then, Python eliminates the ambiguity and resolves intention with indentation. If it looks like it belongs to a block, then it does.

Like so many Python converts, I was initially skeptical of this entire process. My license plate used to read "USE PERL"! However, since writing "real" code in Python, and extending someone else's "very large" project in C, I confess that I now realize using indentation for blocking is the "right" answer, as long as we're presuming a text-based language :)

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

MAXOMENOS (9802) | more than 13 years ago | (#276793)

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 [sourceforge.net] (GPL'd Java ODMG) needs volunteers.

Re:Braces vs Whitespace (1)

tuffy (10202) | more than 13 years ago | (#276794)

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.

In Python, you can wrap code into another line by appending \ at the end of it. Or, if the syntax is unambiguous, even the \ can be dispensed with. For example:

1 + 2 + \
3

Is okay, as is:

1 + (2 +
3)

But:

1 + 2 +
3

will cause complaint.

Re:Braces vs Whitespace (1)

tuffy (10202) | more than 13 years ago | (#276795)

This must be some definition of "lots of work" I was unaware of ;)

In practice, most of the stuff that goes over 80 chars are long lists or function calls, which don't need the \ thingy whatsoever. But, in general, Python tends to reuse the basic syntax for lots of things and so it hasn't exhausted the list of special characters yet - I figure we can spare the \

:)

Re:Indentation syntax has its problems too (1)

hmckee (10407) | more than 13 years ago | (#276796)

Of course you don't know what the code is supposed to do, the code is just an example. That's the problem using contrived code as an example; they provide no context to explain what the code is supposed to do.

If I were working on a project and saw some stray code with cryptic variables such as x and y being assigned to for no apparent reason, I would question whoever wrote the code.

Code from the above example should REQUIRE some comments explaining what x and y are and why they are being changed.

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

Shadowlore (10860) | more than 13 years ago | (#276797)

Uhh you do realize that the license on Python is for PYTHON and not for apps coded in Python, right?

Re:"State" of Virginia? (1)

toriver (11308) | more than 13 years ago | (#276799)

Well, they're not on the list [swishweb.com] , so they may have some other strange definition instead of the common meaning.

Too bad, he "skipped" the comparison with Ruby. (1)

renoX (11677) | more than 13 years ago | (#276800)

As I'm a language freak, I like comparison between languages.

I said COMPARISON not FLAME WARS.

I understand that he must be very busy, but I think that he should take the time to look at Ruby because IMHO it competes in the "same space" (a clean scripting language).

Know thy competitor, even if it is only to steal its bests idea :-).

Re:Braces vs Whitespace (2)

elmegil (12001) | more than 13 years ago | (#276806)

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 (5)

elmegil (12001) | more than 13 years ago | (#276807)

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 (2)

Sloppy (14984) | more than 13 years ago | (#276812)

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


---

the GPL is not a contract (3)

sethg (15187) | more than 13 years ago | (#276814)

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:Braces vs Whitespace (1)

Shadowlion (18254) | more than 13 years ago | (#276816)

But is this the fault of the language, or the fault of the editor?

As much as I love vi (and I do love vi), this strikes me as more a deficiency of the editor rather than a problem with the language. Languages should not conform to the available tools, but instead the available tools should adapt to incorporate new language concepts.


--

Re:Braces vs Whitespace (1)

Shadowlion (18254) | more than 13 years ago | (#276817)

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

It's not the responsibility of a language to conform to the features offered by existing editors. In fact, it's just the opposite: editors exist to help edit, and as a result are responsible for adapting to new languages (that is, assuming you want that editor to help the user program more efficiently).

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.

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

As for your first case, Python probably spits out an error. But it's analogous to asking, "What happens if instead of curly braces in C, you put in square braces?" Tabbing is defined as something that matters by the _language_, and if you don't do what the language tells you, it's not the language's fault your code doesn't run!

If Joe Schmoe puts in 8 spaces, followed by a tab, it's not Python's fault. Schmoe should've known that spaces are illegal characters (at least as he is using them). You don't bitch and moan about Python's "inability" to ignore whitespace, you bitch and moan at Joe! (Would you bitch and moan at C if some programmer decided he wanted to use straight braces instead of curly ones?)

--

Re:Easily overlooked - not. (1)

Shadowlion (18254) | more than 13 years ago | (#276818)

Why not have the parser spit out a 'suspicious construct' warning instead?

Because the parser would wind up spitting out an error for every multi-line block you had. In a throwaway example, such as this, it works out okay. In an app with thousands, or tens of thousands of lines of code, I shudder to think of the number of messages the parser would display.


--

Re:Indentation syntax has its problems too (2)

ChadN (21033) | more than 13 years ago | (#276824)

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

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

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

Re:To all you whiners (2)

irix (22687) | more than 13 years ago | (#276825)

Yeah, and C supports indentation delimiting too:

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

...

Python Block Delimited Notation Parsing Explained (1)

Phill Hugo (22705) | more than 13 years ago | (#276826)

http://www.python.org/doc/Humor.html#parsing [python.org]

http://www.python.org/doc/Humor.html#parsing

The over cautious "junk character lameness filter" wouldn't let me quote it, but do look at it, its funny.

That's where code formatters come into play... (2)

SuperKendall (25149) | more than 13 years ago | (#276830)

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.

Licence issues (1)

The Toad (25382) | more than 13 years ago | (#276831)

I don't understand what Guido is whining about. Eben's response seemed polite, rational, and reasonable.

The issues with the license are very minor and I'd like to know why Guido has a problem with the FSF's recommendations.

(sorry about the repost - why does slashdot keep randomly forgetting who I am?)

Guido Van Rossum is Dutch not Italian (nt) (1)

Vamphyri (26309) | more than 13 years ago | (#276833)

nt

Re:"State" of Virginia? (1)

pthisis (27352) | more than 13 years ago | (#276834)

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

VA can call itself whatever it wants to, but under the US Constitution it's a state--and the Constitution is the supreme law of the land, accepted by VA over 250 years ago.

And the link you gave was to www.STATE.va.us...

Sumner

Re:Braces vs Whitespace (2)

pthisis (27352) | more than 13 years ago | (#276835)

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

My Favorite Python Sketch .... (1)

opencode (28152) | more than 13 years ago | (#276836)

is about the trained idiot. with "many aparati available in his backyard designed to keep him [John Cleese] silly" ....

Oh, and of course, the lumberjack song with footnote: "Dear sir, I find the preceeding bit about lumberjacks dressing in women's clothing both highly offensive dispicable. For I have several close friends who are lumberjacks, and only a few of them are actually transvestites."

Re:Braces vs Whitespace (2)

Russ Nelson (33911) | more than 13 years ago | (#276843)

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:Licence issues (2)

Russ Nelson (33911) | more than 13 years ago | (#276844)

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

Russ Nelson (33911) | more than 13 years ago | (#276845)

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

GPL is fundamentally broken, sorry. (4)

Russ Nelson (33911) | more than 13 years ago | (#276850)

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:Indentation syntax has its problems too (1)

nevets (39138) | more than 13 years ago | (#276853)

syntex. " [sic] At least I got it right in the subject :-)

Actually, you missed my point.

If for some reason I hit the tab on the "y" part, I would not know it was a mistake until I really analyze the code. It is not as easy to make a mistake with adding the "}" in the wrong place. Yes it can be done, but not as easily. It is easier to make indentation mistakes in Python, and that will be harder to spot it, especially if you have long code segments and get messed up in the nesting structure. Maybe you could add begin and end comment statements to help in this, but that is an overhead that few, if any, programmers will do.

My preferred scripting language is Perl, and a coworker of mine prefers Python. We both make fun of each other and have debates on the issue all the time. But this one point, he actually agrees with me.

There are those that like the Python way, and there are those that like the Perl way. This is a Holy war and will never end. So, I too believe that Python will be around in 20 years (although it may change) but I also believe that Perl will be around in 20 years. This is the case because it is a Holy war, and as we can learn from the Mid East, they can last a long time.

Steven Rostedt

Indentation syntax has its problems too (2)

nevets (39138) | more than 13 years ago | (#276854)

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

Implementation *Not* Driving Semantics? (1)

Curly (49104) | more than 13 years ago | (#276860)


[...] one of my reasons against adding Scheme-style continuations to the language [...] 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.


Clearly!

R and Python (2)

hopeless case (49791) | more than 13 years ago | (#276861)

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.

indentation, yes. ...but with a gripe. (1)

thunderbug (51999) | more than 13 years ago | (#276862)

I like Python's indentation rules. I didn't at first, but I do now. BUT sharing and modifying code is is often a problem, sorry to say.

What I find a disconcerting is that some folks use 4 spaces and I use a tab set at four spaces. They are not the same and between autoindent and my hitting the tab key, I get some very interesting combinations. Finding the problem can be difficult without a utility.

It gets even more interesting when I get code that assumes tabs of 8, and because that is too much, 4 spaces are used for the intermediate levels. ...and it is not always obvious that is what's happening.

Can we agree on a convention? ...or perhaps some pseudo code for the parser?

Re:Braces vs Whitespace (2)

bnenning (58349) | more than 13 years ago | (#276869)

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

Definitely overlookable (1)

jacobm (68967) | more than 13 years ago | (#276876)

When you look at it in the abstract, in a "look at the bug in this fragment" sort of a way, it's obvious. But I've lost at least an hour or so to debugging that sort of thing, and back when I used to be a lab assistant for a beginning programming class I saw people making that error all the time.
--
-jacob

Hrmph! (3)

jacobm (68967) | more than 13 years ago | (#276878)

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

Get over it!

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

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


--
-jacob

Re:indentation, yes. ...but with a gripe. (1)

fanatic (86657) | more than 13 years ago | (#276887)

And this is by itself enough reason for me to never use Python. At least twice, I've found myself reading about Python and thinking it's kind of neat sounding, but I always hit the part about syntactically significant whitespace and say, 'No, I think I'll pass'. I admit I'm partial to Perl.

--

Re:Answer the question, dammit! (1)

Cheetahfeathers (93473) | more than 13 years ago | (#276889)

When it makes a difference if you use tabs or spaces, this makes it _less_ readable, because on reading, they _look_ the same. I cut and pasted some tutorial examples from the web a while back, and it wouldn't work until I made the blasted things tabs rather than spaces.

Whitespace as part of the syntax... personally annoying to me, but I can deal. Differentiating between different _types_ of whitespace? That is _BAD_!

Re:My Favorite Python Sketch .... (1)

F452 (97091) | more than 13 years ago | (#276890)

Of the many good scenes from the Holy Grail, this is one of my favorites:

ARTHUR
Old woman!
DENNIS
Man!
ARTHUR
Man. Sorry. What knight lives in that castle
over there?
DENNIS
I'm thirty-seven.
ARTHUR
I-- what?
DENNIS
I'm thirty-seven. I'm not old.
ARTHUR
Well, I can't just call you 'Man'.
DENNIS
Well, you could say 'Dennis'.
ARTHUR
Well, I didn't know you were called 'Dennis'.
DENNIS
Well, you didn't bother to find out, did you?
ARTHUR
I did say 'sorry' about the 'old woman',
but from the behind you looked--
DENNIS
What I object to is that you automatically treat
me like an inferior!
ARTHUR
Well, I am King!
DENNIS
Oh, King, eh, very nice. And how d'you get that, eh?
By exploiting the workers! By 'anging on to outdated
imperialist dogma which perpetuates the economic and
social differences in our society. If there's ever
going to be any progress with the--

and so on...

FSF cares but goes too far (2)

Christianfreak (100697) | more than 13 years ago | (#276894)

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:Braces vs Whitespace (2)

Fencepost (107992) | more than 13 years ago | (#276898)

[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:Easily overlooked - not. (1)

ekidder (121911) | more than 13 years ago | (#276902)

I would write
if (x > 10) x = 10;
as
x = 10

if ( x > 10 );
instead. For me, single-line if clauses get put the other way around. This is to prevent ambiguity and because I was tired of putting braces around a single line :) The indention ideal that Python uses just doesn't work with my style at all - I've tried the language and put it back.

Quibbles about the 2.1 Lic. (2)

jallen02 (124384) | more than 13 years ago | (#276905)

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

RevAaron (125240) | more than 13 years ago | (#276907)

The bloody GPL always causing problems. If you don't like Python's license, don't use it. If RMS and his clan of Gnuzis don't like it, they shouldn't bitch, they should just get over it, and not use it. Or, if it really mattered, make a new implementation of Python covered under the GPL. Or, if you don't like the GPL, boycott code written under it when it effects your life adversely.

Re:Argh. We need license compatibility. (2)

RevAaron (125240) | more than 13 years ago | (#276908)

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.

Re:Braces vs Whitespace (1)

rattdot (125708) | more than 13 years ago | (#276909)

Agreed... whitespace blocking makes me think of --- horror of horrors --- VB. Thus it must be bad, right? ;)

Re:Guido van Rossum Unleashed? (1)

e-Motion (126926) | more than 13 years ago | (#276911)

May I assume that the following books will also be available soon? Instant Guido van Rossum ....

I'm personally waiting for my copy of Guido van Rossum How To Program.

The FSF has some good points (3)

legLess (127550) | more than 13 years ago | (#276912)

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

Conclusion: in order to be "compatible" in the strict sense, we need paragraph 7 to remove the choice of law clause. We would also recommend that paragraph 8 be changed to say that copying, modification or distribution constitutes acceptance of the license, but we don't have to have that change to agree that the license is fully "GPL compatible."
They've given him one requirement to make the license fully GPL-compatible, and IMHO it's very reasonable. Virginia, folks, is a very scary place to license software. If you haven't read up on UCITA, do so [ucita.com] .

So we have never allowed a license with a choice-of-law clause to be treated as fully compatible with GPL. Virginia is the worst of all choices, because that state has passed the UCITA law, which adds a whole new range of risks and burdens in the distribution of free software.
Now, CNRI's lawyers might not like that, but their job is to do one thing: cover CNRI's ass. That's well and good, but the GPL has loftier goals: guaranteeing our freedoms.

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

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

Re:Indentation syntax has its problems too (3)

wrygrin (128912) | more than 13 years ago | (#276913)

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.

Oh Well (1)

ekrout (139379) | more than 13 years ago | (#276914)

I was hoping for +1, Funny on the "parent" of this post, but oh well. "You can't...always get...what ya wa-ant!"

Re:Braces vs Whitespace (1)

Nohea (142708) | more than 13 years ago | (#276916)

Aren't tabs vs. spaces the reason the makefile format is universally hated?

Said about as much as the lawyers! (1)

BobTheWonderMonkey (144907) | more than 13 years ago | (#276919)

Was anyone else completely nonplussed by these answers? I'm not sure anything was said!

Re:Indentation syntax has its problems too (1)

swamp boy (151038) | more than 13 years ago | (#276921)

While I'm one of the "I wish it had explicit delimiters" camp, I settled on the following convention involving comments that seems to work for me.

if x == 10:
# end if

while not done:
# end while

for x in y:
# end for

It's still not quite as getting a quick visual alignment of curly braces (I put my open brace aligned with my close brace), after a little practice it's easy to discern blocks.

YMMV!

Re:Braces vs Whitespace (2)

connorbd (151811) | more than 13 years ago | (#276922)

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

Unfavorable View of the FSF? (1)

EraseEraseMe (167638) | more than 13 years ago | (#276926)

He seems to have had quite a trouble handling the FSF's many hoops to jump through. Were the problems he encountered caused by the FSF's focus on protecting the community, on protecting the original developer, or protecting itself? I hope that this could be clarified by a followup interview, or maybe Guido himself could post with his opinions in a bit more detail

Re:"State" of Virginia? (1)

sulli (195030) | more than 13 years ago | (#276932)

Well, http://www.commonwealth.va.us [commonwealth.va.us] is 404... really they should have that, for the purists among us.

"State" of Virginia? (2)

sulli (195030) | more than 13 years ago | (#276933)

Well, Virginia is a Commonwealth, [state.va.us] as any Virginian knows, so that might be part of the problem!

what he said (MOD PARENT UP PLS) (1)

mkcmkc (197982) | more than 13 years ago | (#276935)

I'm sure it's been a long and tedious road, but solving this really matters.

My project, SUBTERFUGUE [subterfugue.org] , is written in Python, GPL'ed, and included in Debian, so I have a (small) dog in this race.

The FSF has been right about things so far. If you truly disagree with them, make that argument to them (and us). But please don't let exhaustion be the reason for just letting things drop in the current murky state.

--Mike

Re:Braces vs Whitespace (2)

keesh (202812) | more than 13 years ago | (#276939)

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 (2)

keesh (202812) | more than 13 years ago | (#276940)

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

Re:Braces vs Whitespace (1)

wmulvihillDxR (212915) | more than 13 years ago | (#276942)

Not to mention what happens when you edit your Python programs across different text editors AND different platforms. I've already run into many character mapping problems with OSX transfers. Tabs and spaces can get mangled differently by different text editors too!

Re:Licence issues (1)

aburnsio.com (213397) | more than 13 years ago | (#276943)

Why does the FSF obsess over license issues? One word: RMS. I dare you to meet him in person and say something even remotely non-GPL compatible and see what happens. It's not pretty.

The easiest way to GPL compatibility (2)

RedLaggedTeut (216304) | more than 13 years ago | (#276945)

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.

Easily overlooked - not. (1)

mike260 (224212) | more than 13 years ago | (#276946)

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;


Is it just me, or is that an instantly suspicious-looking piece of code? I don't think it's 'easily overlooked' at all, it doesn't look like regular C/C++ at all.
Easy to say in retrospect I suppose, but still...

---
Fruity smells are what I like -- Debbie Gibson

Re:Easily overlooked - not. (1)

mike260 (224212) | more than 13 years ago | (#276947)

Heh, I can't believe I missed that.

I was talking about the bracketing/indentation when I said 'doesn't look like regular C/C++' though.

Re:Easily overlooked - not. (1)

mike260 (224212) | more than 13 years ago | (#276948)

I now realize using indentation for blocking is the "right" answer

Unfortunately, along with a few others I've had the "wrong" answer burnt into my brain by years of reinforcement. Why not have the parser spit out a 'suspicious construct' warning instead? It would prevent the bugs you describe just as well, and would be one less new trick for old dogs like myself to get rewire their neurons around.

Re:Braces vs Whitespace (1)

gunga (227260) | more than 13 years ago | (#276955)

Well obviously this feature will stay in Python, so there's no use discussing it for ages.

If it prevents you from coding, fine they're are other languages that share some of Python's most interesting features.

I honestly can't see the interest of this discussion, I'm not telling anyone to shut up of course, but you don't have to use Python if it don't suits you.

Guido van Rossum Unleashed? (2)

Slashdot Cruiser (227609) | more than 13 years ago | (#276956)

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

Re:FSF love or hate? (1)

FastT (229526) | more than 13 years ago | (#276957)

No we don't.

Parrot for Dummies (2)

Anonymous Cowturd (231830) | more than 13 years ago | (#276958)

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

MeowMeow Jones (233640) | more than 13 years ago | (#276959)

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:

FSF love or hate? (1)

mjisgod (242501) | more than 13 years ago | (#276961)

Its funny, in some /. postings the FSF is villified, while others they are made out to be gods.

At least we all agree on one thing, M$ is EVIL!

Problem with Python... (2)

MadCow42 (243108) | more than 13 years ago | (#276962)

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.

Lawyors vs. Java (1)

noz (253073) | more than 13 years ago | (#276964)

I believe I speak for all when I say that we wish you the best of luck in getting your dealings with the lawyors to work better than those damn JVMs. My ex-girlfriend's dad is a lawyor, so I've had my fair share of dealings with them. cPython all the way!

Re:Braces vs Whitespace (1)

dachshund (300733) | more than 13 years ago | (#276967)

As far as I'm concerned, the indentation issue is a non-starter

I have yet to use Python, and reading about this issue has made me a little bit nervous about starting.

One of the more irritating problems I encounter when sharing code between Windows and Unix machines (not to mention various text editors) is the inconsistent indentation. This is mostly due to bad text editors interpreting tabs differently. A few CVS checkins later, code can look like it was hit with a shotgun blast. Now this is basically cosmetic with C and Java, but from what you're saying it could be fatal for Python code. Am I mistaken?

Re:Indentation syntax has its problems too (1)

dachshund (300733) | more than 13 years ago | (#276968)

Code from the above example should REQUIRE some comments explaining what x and y are and why they are being changed.

Regardless of how well labeled/commented the code is, a complex program is tougher to debug when you have to carefully read through every comment to determine whether there's been a (probably text-editor related) indentation mistake.

Agh, can you imagine debugging something like an MPEG encoder that way?

Re:Indentation syntax has its problems too (1)

dachshund (300733) | more than 13 years ago | (#276969)

As was said in the above replies, it's probably a failing of C that it allows you to use the undelimited form. However, that hunk of C code will still have the same meaning even if some moron checks it out on their Win2000 box and screws up all the indentation while using Notepad.

The python code, on the other hand... Well, anything could happen to those indentations. Not to mention that it's a whole lot easier to accidentally hit/fail-to-hit a tab key then to skip a pair of curly braces (not that it's unheard of, of course)

use vs. copying (1)

kataklyst (304224) | more than 13 years ago | (#276971)

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

No, the GPL is the terms under which you can copy/modify GPLed software. The GPL grants additional rights beyond what you would get to, say, a newspaper. If you don't agree to the GPL, you may not distribute copies of the work. However, you may still use it in any way you like, just as you may use a newspaper.

Re:GPL is fundamentally broken, sorry. (2)

ryants (310088) | more than 13 years ago | (#276972)

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:Perl, perl and PERL (1)

utopian (311467) | more than 13 years ago | (#276977)

probably learnt it from a book with 'PERL' written in 6 inch high gold lettering on the front cover and a promise to be a great programmer 'in hours!'

Re:Licence issues (1)

Tech187 (416303) | more than 13 years ago | (#276986)

Is it because the FSF keeps asking for different things?

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

Re:Braces vs Whitespace (2)

Tech187 (416303) | more than 13 years ago | (#276989)

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

Re:Licence issues (1)

warmiak (444024) | more than 13 years ago | (#276994)

He is not whining about anything.
I often feel the same "tiredness" of dealing with supposedly free GPL.
For a "free" license it sure makes you go through many hoops, checking and double checking that everything fits well into FSF mindset and their vision of what free software is about.

Re:The FSF has some good points (2)

warmiak (444024) | more than 13 years ago | (#276995)

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

Re:Indentation syntax has its problems too (1)

moocat2 (445256) | more than 13 years ago | (#276996)

Braces are not always the answer. Did the programmer forget to indent the second line in the block or did he put the line in the wrong place?

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

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?