Guido van Rossum Unleashed 241
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:
So, my question is a two parter: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.
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)
Re:Indentation syntax has its problems too (Score:1)
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 (Score:1)
"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
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 (Score:1)
I'm honestly curious -- I've experienced none of these problems (or, at least, when I did it was obvious enough that I wouldn't remember it). Not a one.
Re:Braces vs Whitespace (Score:1)
Try it. You'll like it.
Re:Braces vs Whitespace (Score:1)
Re:That's where code formatters come into play... (Score:1)
Actually, Python does an excellent job of figuring out how many spaces you intend a tab to be. I say this from the point of view of someone who switched from emacs to vim about a year ago, and made some corresponding changes in code style and tab-versus-space usage (no longer doing things the way the emacs mode I was using insisted on). I can still edit my old python files -- and if they look right in the editor, they run correctly in the interpreter every time, mixed code or no.
Thus, however delicate the whitespace-dependancy system may appear in theory, it's wonderfully robust in practice.
As for having systems which let you format things the way you want... one of the nice things about Python is that it enforces a system which is readable by everyone. There's no more messing with reformatters or debating code styles -- there's one obvious style, And It Is Good. Frankly, I like that.
Re:Indentation syntax has its problems too (Score:1)
Yup. It's sweet. Really. Try it.
Re:Indentation syntax has its problems too (Score:1)
but then, vim users *like* the pain, right? .
Re:Braces vs Whitespace (Score:2)
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 (Score:2)
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.
Re:Braces vs Whitespace (Score:1)
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 (Score:1)
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 (Score:2)
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 (Score:2)
YADNAL (Score:1)
Re:YADNAL (Score:1)
Yes, the license is still the same. However, it's not a valid contract, and you need a contract to disclaim warranty.
Following your logic, if I steal some software from someone, they can't disclaim warranty, because there was no contract, and therefore I can sue them for damages the software does.
The GPL can be declined. Indeed, you are not accepting the GPL unless you use the source code or a binary derived from the source code. That is plenty to establish a contract.
I agree the jurisdiction thing is problematic. I assume that FSF's lawyers figured it was the only way to do it. It's amazing that the hardest thing in the world to do legally is give something away without any liability.
Re:YADNAL (Score:2)
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:Braces vs Whitespace (Score:2)
Re:Braces vs Whitespace (Score:2)
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 (Score:1)
To all you whiners (Score:1)
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 (Score:2)
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 (Score:2)
-Billy
Re:Braces vs Whitespace (Score:3)
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 (Score:2)
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.
Python is fun! (Score:1)
First off, I'll confess to being a language junkie. I like to learn programming languages, and I enjoy playing with them. Secondly, my bread and butter languages are C and Perl, which I like and dislike about equally.
So I've played with Python. Written a few small programs (some for personal use, a couple at work)... What none of these so-called Python advocates are mentioning is that programming in Python is fun.
I wish I could quantify it better, but I've actually found myself chuckling as a Python program came together.
Bander
p.s. Some of you people who think the block syntax in Python is too weird should take a look at Scheme or FORTH... Some of us used to program with a line-number oriented language without any real block structure at all. Back in those ancient days, we called it BASIC and liked it. :^)
--
Argh. We need license compatibility. (Score:5)
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
Re:"State" of Virginia? (Score:1)
Yes, and if they were trying to get the license interpreted under US law, that would probably be effective. They're not, it won't work, and you're a moron for not noticing that. Try not to dabble in legal work, you obviously don't have the powers of concentration needed.
Re:Argh. We need license compatibility. (Score:4)
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.
I agree (Score:1)
Python is why I chose not to GPL my DNS server (Score:2)
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 (Score:2)
...
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 (Score:2)
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. (Score:3)
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:Python is why I chose not to GPL my DNS server (Score:2)
ObJectBridge [sourceforge.net] (GPL'd Java ODMG) needs volunteers.
Re:Braces vs Whitespace (Score:2)
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){
For one thing, different tab stops screw up virtually every language, not just Python.{{{{{
{{{{{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...
Only in terms of how "pretty" the source code is - none of the languages I've ever worked with (not that there are that many, nor that I'm a "master" of any of them, but...) actually had any problems due to varying tab sizes when it came time to actually compile and/or run the program
In other words, I think the problem is fundamentally that people who don't feel comfortable with Python mainly dislike the way it almost fits the definition of a bondage-and-discipline language [tuxedo.org] (except that I think the amount of useful stuff being written in Python easily disproves the "demonstrably inadequate for...even vanilla general-purpose programming" clause, regardless of whether I dislike the syntactical quirks of the language or not:-) ) and don't like feeling so constrained.
---
Re:Braces vs Whitespace (Score:2)
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 (Score:5)
Re:Braces vs Whitespace (Score:2)
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.
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:the GPL is not a contract (Score:2)
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 (Score:3)
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 (Score:2)
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:Indentation syntax has its problems too (Score:2)
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 (Score:2)
if(a==b)
{
/* ignore previous line please */
a = c;
...
That's where code formatters come into play... (Score:2)
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.
Re:Braces vs Whitespace (Score:2)
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=
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
Sick of Perl/perl/PERL bigots.. (Score:2)
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:Braces vs Whitespace (Score:2)
-russ
Re:Licence issues (Score:2)
But sometimes I wonder if the GPL wasn't devised to enhance uncertainty.
-russ
Re:Easily overlooked - not. (Score:2)
-russ
No. There is no opportunity for acceptance or rej (Score:2)
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 (Score:2)
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 (Score:2)
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? (Score:2)
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. (Score:4)
The GPL warranty disclaimer can't work.
-russ
Re:Braces vs Whitespace (Score:2)
Re:Problem with Python... (Score:2)
Indentation syntax has its problems too (Score:2)
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
R and Python (Score:2)
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? (Score:2)
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:Braces vs Whitespace (Score:2)
Vi doesn't. But I only use vi when I have to. I never want to.
- - - - -
Re:Braces vs Whitespace (Score:2)
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 (Score:2)
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 (Score:2)
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 (Score:3)
:":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
:" moves the cursor to position found by 'Moveup()'
:map
--Robert
Re:Argh. We need license compatibility. (Score:2)
From the DFSG:
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! (Score:2)
--
-jacob
Hrmph! (Score:3)
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 syntax has its problems too (Score:2)
FSF cares but goes too far (Score:2)
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 (Score:2)
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:Whitespace and Python as a Teaching Tool (Score:2)
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 (Score:4)
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. (Score:2)
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. (Score:2)
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 (Score:3)
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].
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 (Score:3)
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.
Re:FSF cares but goes too far (Score:2)
Go read gnu.org [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.
Frustrated with this interview (Score:2)
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:Braces vs Whitespace (Score:2)
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:Guido van Rossum Unleashed? (Score:2)
How about the following for Linux hackers:
or any other *shell for that matter. Which reminds--
It's hard to beat The Cheese Shoppe .... (Score:2)
Curious George
"State" of Virginia? (Score:2)
Re:Braces vs Whitespace (Score:2)
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 (Score:2)
The easiest way to GPL compatibility (Score:2)
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.
Re:Braces vs Whitespace (Score:2)
Guido van Rossum Unleashed? (Score:2)
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 (Score:2)
if 'fruits de mer' = seafood
Re:Too bad, he "skipped" the comparison with Ruby. (Score:2)
Trolls throughout history:
Problem with Python... (Score:2)
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:GPL is fundamentally broken, sorry. (Score:2)
License == Contract ... it is the terms under which you can use/copy/modify GPLed software.
Ryan T. Sammartino
Re:the GPL is not a contract (Score:2)
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:
Ryan T. Sammartino
Re:use vs. copying (Score:2)
That doesn't change the fact that it is a contract.
Ryan T. Sammartino
Re:the GPL is not a contract (Score:2)
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
no answers on efficient compilation (Score:2)
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? (Score:2)
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.
Re:Braces vs Whitespace (Score:2)
Re:Braces vs Whitespace (Score:2)
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:The FSF has some good points (Score:2)
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.