Slashdot Mirror
Guido van Rossum Unleashed
Ruby
by Luke
Thoughts on Ruby?
Guido:
I just looked it up -- I've never used it. Like Parrot, it looks like
a mixture of Python and Perl to me. That was fun as an April Fool's
joke, but doesn't tickle my language sensibilities the right way.
That said, I'm sure it's cool. I hear it's very popular in Japan. I'm not worried.
Data Structures Library
by GrEp
I love python for making quick hacks, but the one thing that
I haven't seen is a comprehensive data structures library.
Is their one in
development that you would like to comment about or point us
to?
Guido:
One of Python's qualities is that you don't need a large data
structures library. Rather than providing the equivalent of a
256-part wrench set, with a data type highly tuned for each different
use, Python has a few super-tools that can be used efficiently almost
everywhere, and without much training in tool selection. Sure, for
the trained professional it may be a pain not to have singly- and
doubly-linked lists, binary trees, and so on, but for most folks,
dicts and lists just about cover it, and even inexperienced
programmers rarely make the wrong choice between those two.
Since this is of course a simplification, I expect that we will gradually migrate towards a richer set of data types. For example, there's a proposal for a set type (initially to be added as a module, later as a built-in type) floating. See http://lists.sourceforge.net/lists/listinfo/python-sets and http://python.sourceforge.net/peps/pep-0218.html.
[j | c]Python
by seanw
How do you see the relationship between jPython (the java
implementation) and standard cPython (the original C
language version)
evolving? And do you see the advantages of either one (i.e.
portability vs. speed) becoming especially pronounced in
light of the recent
trend toward distributed software (ala the MS .NET
initiative)?
Guido:
Note that the new name is Jython, by the way. Check out
www.jython.org -- they're already working on a 2.1 compatible release.
We used to work really close -- originally, when JPytnon was developed at CNRI by Jim Hugunin, Jim & I would have long discussions about how to implement the correct language semantics in Java. When Barry Warsaw took over, it was pretty much the same. Now that it's Finn Bock and Samuele Pedroni in Europe, we don't have the convenience of a shared whiteboard any more, but they are on the Python developers mailing list and we both aim to make it possible for Jython to be as close to Python in language semantics as possible. For example, one of my reasons against adding Scheme-style continuations to the language (this has seriously been proposed by the Stackless folks) is that it can't be implemented in a JVM. I find the existence of Jython very useful because it reminds me to think in terms of more abstract language semantics, not just implementation details.
IMO the portability of C Python is better than that of Jython, by the way. True, you have to compile C Python for each architecture, but there are fewer platforms without a C compiler than platforms without a decent JVM.
Jython is mostly useful for people who have already chosen the Java platform (or who have no choice because of company policy or simply what the competition does). In that world, it is the scripting and extension language of choice.
does Python need a CPAN?
by po_boy
One of the reasons I still write some things in PERL is
because I know that I can find and install about a zillion
modules quickly and
easily through the CPAN repository and CPAN module. I'm
pretty sure that if Python had something similar, like the
Vaults of
Parnassus but more evolved that I would abandon PERL almost
entirely.
Do you see things in a similar way? If so, why has Python not evolved something similar or better, and what can I do to help it along in this realm?
Guido:
It's coming! Check out the action in the catalog-sig
http://python.org/sigs/catalog-sig/. You can help by joining.
One reason why it hasn't happened already is that first we needed to have a good package installation story. With the widespread adoption of distutils, this is taken care of, and I foresee a bright future for the catalog activities.
Favourite Python sketch?
by abischof
Considering that you named the language after the comedy
troupe, what's your favourite Monty Python sketch?
Personally, my favourite
is the lecture on sheep aircraft, but I suppose that's a
discussion for another time ;).
Guido:
I'm a bit tired of them actually. I guess I've been overexposed. :-)
Conflict with GPL
by MAXOMENOS
The Free Software foundation mentions the license that comes
with Python versions 1.6b1 and later as being incompatible
with the GPL.
In particular they have this to say about it:
This is a free software license but is incompatible with the GNU GPL. The primary incompatibility is that this Python license is governed by the laws of the "State" of Virginia in the USA, and the GPL does not permit this.So, my question is a two parter:
1.What was your motivation for saying that Python's license is governed by the laws of Virginia?
2.Is it possible that a future Python license could be GPL-compatible again?
Guido:
Let me answer the second part first. I asked the FSF to make a clear
statement about the GPL compatibility of the Python 2.1, and their
lawyer gave me a very longwinded hairsplitting answer that said
neither yes nor no. You can read for yourself at
http://www.python.org/2.1/fsf.html. I find this is very
disappointing; I had thought that with the 1.6.1 release we had most
of this behind us, but apparently they change their position at each
step in the negotiations.
I don't personally care any more whether Python will ever be GPL-compatible -- I'm just trying to do the FSF a favor because they like to use Python. With all the grief they're giving me, I wonder why I should be bothered any more.
As for the second part: most of you should probably skip right to the next question -- this answer is full of legal technicalities. I've spent waaaaaaaaay to much time talking and listening to lawyers in the past year! :-(
Anyway. The Python 1.6 license was written by CNRI, my employer until May 2000, where I did a lot of work on Python. (Before that, of course, I worked at CWI in Amsterdam, whom I have to thank for making my early work on Python possible.) CNRI own the rights to Python versions 1.3 through 1.6, so they have every right to pick the license.
CNRI's lawyers designed the license with two goals in mind:(1) maximal protection of CNRI, (2) open source. (If (2) hadn't been a prerequisite for my employment at CNRI, they would have preferred not to release Python at all. :-)
Almost every feature of the license works towards protecting CNRI against possible lawsuits from disappointed Python users (as if there would be any :-), and the state of Virginia clause is no exception. CNRI's lawyers believe that sections 4 and 5 of the license (the all caps warnings disclaiming all warranties) only provide adequate protection against lawsuits when a specific state is mentioned whose laws and courts honor general disclaimers. There are some states where consumer protection laws make general disclaimers illegal, so without the state of Virginia clause, they fear that CNRI could still be sued in such a state. (Being a consumer myself, I'm generally in favor of such consumer protection laws, but for open source software that is downloadable for free, I agree with CNRI that without a general disclaimer the author of the software is at risk. I'm happy that Maryland, for example, is considering to pass a law that makes a special exception for open source software here.)
Python 1.6.1, the second "contractual obligation release" (1.6 was the first), was released especially to change CNRI's license in a way that resolved all but one of the GPL incompatibilities in the 1.6 license. I'm not going to explain what those incompatibilities were, or how they were resolved. Just look for yourself by following the "accept license" link at http://www.python.org/1.6.1/. The relevant changes are all in section 7 of the license, which now contains several excruciating sentences crafted to disable certain other clauses of the license under certain conditions involving the GPL. Read it and weep.
The remaining incompatibility, according to the FSF, is the "click-to-accept" feature of the license. This is another feature to protect CNRI -- their lawyers believe that this is necessary to make the license a binding agreement between the user and CNRI. The FSF is dead against this, and their current position is that because the GPL does not require such an "acceptance ceremony" (their words), any license that does is incompatible with the GPL. It's like the old story of the irresistible force meeting the immovable object: CNRI's lawyers have carefully read the GPL and claim that CNRI's license is fully compatible with the GPL, so you can take your pick as to which lawyer you believe.
Anyway, I removed the acceptance ceremony from the 2.1 license, in the hope that this would satisfy the FSF. Unfortunately, the FSF's response to the 2.1 license (see above) seems to suggest that they have changed their position once again, and are now requesting other changes in the license. I'm very, very tired of this, so on to the next question!
Structured Design.
by Xerithane
First off, as a disclaimer I have never actually written
anything in Python. But, I have read up on virtually all the
introduction articles and
tutorials so I have a grasp on syntax and structure.
I have been doing C development for 9 years now, and I know a plethora of other languages including shell scripting, perl, PHP (for scripts). Now, each language uses 'normal' grouping for control structures (if, for, etc).
What was the logic behind creating a whitespace-based syntax rule? And why do you feel it is good, please refrain from the readability answer because that is all I get from those people I know who know Python.
I find, because of my background, it is much easier to read code that uses braces ({}) than whitespace because my mind automatically looks for them. After maintaining legacy code that extends a life span of 20 years from it's first line of code, I have some concerns about the longevity of any Python code. So, my second question is, how well do you see Python holding up for 20 years and why do you think it will hold up that long?
Guido:
What's wrong with the legibility answer? I think that's an
*excellent* reason! Don't care if your code is legible?
Don't you hate code that's not properly indented? Making it part of the syntax guarantees that all code is properly indented!
When you use braces, there are several different styles of brace placement (e.g. whether the open brace sits on the same line as the "if" or on the next, and if on the next, whether it is indented or not; ditto for the close brace). If you're used to code written in one style, it can be difficult to read code written in another. Most people, when skimming code, look for the indentation anyway. This leads to sometimes easily overlooked bugs like this one:
if (x 10)
x = 10;
y = 0;
Still not convinced? In 1974, Don Knuth predicted that indentation
would eventually become a viable means of structuring code, once
program units were small enough. (Full quotation:
http://www.amk.ca/quotations/python-quotes/page-1.html)
Still not convinced? You admit that you haven't tried it yet. Almost everybody who tries it gets used to it very quickly and end up loving the indentation feature, even those who hated it at first. There's still hope for you!
So, no, I'm not worried about Python holding out 20 more years.
What is *your* idea of Python and its future?
by Scarblac
There are a lot of "golden Python rules" or whatever you
would call them, like "explicit is better than implicit",
"there should be only one
way to do it", that sort of thing. As far as I know, those
are from old posts to the mailing list, often by Tim Peters,
and they've become
The Law afterwards. In the great tradition of Usenet
advocacy, people who suggest things that go against these
rules are criticized. But
looking at Python, I see a lot more pragmatism, not rigid
rules. What do you think of those "golden rules" as they're
written down?
What's your idea of the future of Python? Since the PEP process, a lot of new feature ideas have been put forward, and a lot of people feel uncomfortable with quick change to a good language (Python 2.1 is again excellent though, congrats). Do you think or hope Python will be finished one day? If not, isn't the alternative an endless string of added features? "Python 3000" was an idea of a sort of ideal Python that would be worked on, but as I understand Python will now evolve more gradually.
Guido:
You're referring to the "Zen of Python", by Tim Peters:
http://www.python.org/doc/Humor.html#zen
It's no coincidence that these rules are posted on the Python Humor page!
Those rules are useful when they work, but several of the rules warn against zealous application (e.g. "practicality beats purity" and and "now is better than never").
While we put "There's only one way to do it" on a T-shirt, mostly to poke fun at Larry Wall's TMTOWTDI, the actual Python Zen rule reads: "There should be one-- and preferably only one -- obvious way to do it." That has several nuances!
Regarding the future, I doubt that any piece of software ever stops evolving until it dies. It's like your brain: you never stop learning. Good software has the ability to evolve built in from the start, and evolves in a way that keeps the complexity manageable.
Python started out pretty well equipped for evolution: it was extensible at two levels (C extension modules and Python modules) that didn't require changing the language itself. We've occasionally added features to support evolution better, e.g. package namespaces make it possible to have a much large number of modules in the library, and distutils makes it easier to add third party packages.
I hear the complaints from the community about the rate of change in Python, and I'm going to be careful not to change the language too fast. The next batch of changes may well be aimed at *reducing* complexity. For example, there are PEPs proposing a simplification of Python's numeric system (like eradicating the distinction between 32/64-bit ints and bignums), and I've started to think seriously about removing the distinction between types and classes -- another simplification of the language's semantics.
Strangest use of Python
by Salamander
What use of Python have you found that surprised you the
most, that gave you the strongest "I can't believe they did
that" reaction?
Guido:
I find few things strange.
For the most obfuscated code I've ever come across, see the Mandelbrot set as a lambda, http://www.python.org/doc/FAQ.html#4.15.
Digital Creations has written a high-performance fully transactional replicated object database in Python. That's definitely *way* beyond what I thought Python would be good for when I started.
Some people at national physics labs like LANL and LLNL have a version of Python running on parallel supercomputers with many hundreds of processors. That's pretty awesome.
But my *favorite* use of Python is at a teaching language, to teach the principles of programming, without fuss. Think about it -- it's the next generation!
--Guido van Rossum (home page: www.python.org/~guido)
"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 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:
:x,:y,:z,:numInst
"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
What editor do you use? If emacs, do you use python-mode?
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.
Try it. You'll like it.
Check the post mine was parent to -- I wasn't replying to you (nothing trollish about 'ya) but a rather rude AC, who did indeed mention productivity.
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.
Yup. It's sweet. Really. Try it.
but then, vim users *like* the pain, right? .
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?)
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.
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.
Microsoft is to software what Budweiser is to beer.
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.
Microsoft is to software what Budweiser is to beer.
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.)
Microsoft is to software what Budweiser is to beer.
The GPL is a license which defines the terms and conditions of a contract under which you can use the copyrighted material. If you don't accept the terms of the license, and you use the IP covered by the license, then you need to be able to produce some other contract which gives defines the terms under which you get (or more likely get to use) the IP. This is no different from any of those shrink wrap licenses you get with commercial software. When you get commercial software, you aren't actually getting anything more than a license which allows you to do certain things with the code. To follow your analogy, they aren't giveing you the hamburger, just the right to smell the hamburger under certain restrictions. If the GPL can't be enforced, then at the VERY least all of those licenses that you have to accept to get freely available (but proprietary) code are invalid (this covers Java, tons of MS software, most of Stroud's CWS apps, etc.), let alone software sold for $.
sigs are a waste of space
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 for those of you who have not seen this before.
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.
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. :^)
--
What we need more of is science!
Guido:
Please take a deep breath and go in for one last go-around with the FSF lawyers. Pretty please?
As far as I could tell, the remaining issues are just "legalese exhaustion" on your part rather than actual conflicting goals. Maybe you could deputize a legalese wrangler to finish negotiations for you, or you could take a month-long break in which you never think a single thought about licenses, and then you go back and finish the negotiations.
This is really important to me, although I am not a GPL fanatic, because if it remains the case that the licenses are (allegedly) incompatible, then there will be lots and lots of people who will refuse to combine GPL code with Python, and that would really suck.
For example, I want to package up my open source application Python, Mojo Nation to be included in Debian. This would be a way to reach hundreds of thousands (? maybe fewer. Anyone know how many Debian users there are out there?) of highly clueful users and hackers who would otherwise never install Mojo Nation. The Mojo Nation code source code itself is under the LGPL, and some of the open source libraries that it uses are other under free licenses. Would this cause a legal conflict that would force the debian people to keep it off of their servers? I don't know (since it is LGPL instead of GPL), but I would feel so much better if the Python license were officially GPL compatible.
Regards,
Zooko
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.
Let me point out that the GPL-compatibility doesn't affect software written in Python, only attempts to embed the Python interpreter inside a GPLed program. For example, there's GPLed software written in Java, even though the most commonly used JVM isn't GPLed. Python's license should be irrelevant to whatever license your Python application uses.
Also, note that the Apache license isn't GPL-compatible, yet that doesn't prevent Debian including Apache. I view this debate as a tempest in a teapot; it may affect people who want to do things like embed Python inside the GIMP, say, but most Python users don't have to care.
Python is a great language with a great user community! Please, do yourself a favor, download Python and gve it a try. I let the whitespace issue keep me from using Python for using Python, but my curiosity got me to try it. I'm glad I did.
"Eye halve a spelling chequer, It came with my pea sea, It plainly marques four my revue, Miss steaks eye kin knot sea"
Anyway, I removed the acceptance ceremony from the 2.1 license, in the hope that this would satisfy the FSF. Unfortunately, the FSF's response to the 2.1 license (see above) seems to suggest that they have changed their position once again, and are now requesting other changes in the license. I'm very, very tired of this, so on to the next question!
The main reason I chose to to GPL my latest open source project--the MaraDNS server--was because I knew that there were some incompatibilities between the GPL license and the Python license. As long as the GPL may make it impossible to make a python module out of my code, I am not going to GPL it.
Instead, I made MaraDNS public domain. BTW, I use Python-style syntax for the mararc file MaraDNS uses.
BTW, isn't it against the license for Python to have a gdbm module, since gdbm is GPL and not LGPL? And, is it not inappropriate to have Python KDE bindings or use Python in KDE programs?
- Sam
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
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.
It doesn't matter if you use tabs or whitespaces, provided you use them consistantly. I never use tabs in my Python code, so so much for your theory about it requring tabs...
I think he's doing a remarkable job of remaining cool in the middle of a legal firefight he has almost no influence over.
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:
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 :)
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.
This applies equally well to those who refuse to use python because it uses indentation, would you not agree?
My Suburban burns less gasoline than your Prius.
Well, they're not on the list, so they may have some other strange definition instead of the common meaning.
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
Nah. Nothing beats the cannibalism sketches. Those are downright offensive. :)
If someone violates the GPL, they can still be sued -- but they would be sued for copyright infringement, not contract violation.
--
send all spam to theotherwhitemeat@ropine.com
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.)
--
send all spam to theotherwhitemeat@ropine.com
This License Agreement shall be governed by and interpreted in all respects by the law of the State of Virginia, excluding conflict of law provisions.
I believe the term "this license agreement" refers only to the CNRI license, not to all other agreements that might be offered with respect to the copyrights of other works that Python comprises. For example, the BeOpen material is covered by a California choice-of-law provision. As I read it, the CNRI and BeOpen conditions do not say that the GPL must be interpreted under Virginia or California law, nor do they (nor could they) require that litigation be conducted in California or Virginia.
Also, since CNRI knowingly published their works for years without a copyright notice and knew that these works were being treated as though they were covered by the CWI copying conditions, I think CNRI's copyrights are probably unenforceable because of the "sleeping on your rights" doctine.
On the other hand, I am not a lawyer, so don't take this as legal advice. In fact I'm not even taking my advice: just to be careful, we use a much older version of Python in the Yggdrasil build tree. (Yeah, I know its been years since a release, but there are still nightly builds and now rsync'ing. You could arguably call me crazy for it.).
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.
--
Oh, sorry, my bad.
I thought he meant, why not have the parser spit our an error message in Python, not C. Yeah, if we're talking about C, you're right - it would only pop up in a few rare cases.
However, I can see some other problems with that. In certain C statements (switch/case, I'm looking in your direction!), it _is_ legal to have multiple statements on the next line without being enclosed by a curly brace. The compiler/parser would have to be bright enough to recognize that switch/case is a special case (which doesn't require much intelligence, I guess).
--
Honestly, if you can't deal with simple problems like these, then I wouldn't be comfortable charging you with more complex tasks.
I like the clean simple syntax of Python; It allows me to concentrate on more important issues, like design, in an elegant way. To each his own.
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
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.
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
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.
I've worked on many large projects. There are a couple of scenarios here:
1) A lot of people are activley working on the project. In that case I might very well not check in my modified file, just my changes (merging them back with an interactive diff tool). Or, I'll change one small section of the code to be formatted well and over time the whole thing will be rearranged.
2) I'm reviving an essentially dead project. In this case, if the formatting is especially bad, I'll just reformat some of the worst case and check it in anyway... damn the diffs, at least it's readable.
What are you worried about beyond the diffs? I tend not to worry about space for SCM repositories as individual modules are not large enough that even a whole file change is going to cause a lot of grief.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
You have a very good point about a mode fashioned for a lnaguge in Emacs not letting you indent things incorrectly... that was a bad example.
However, my primary point was that I prefer systems that let me format things the way I wish to make them readable for me.
I can think of other code formatting tools (like something that would turn tabs into 8 spaces) that might case problems if you had some lines with tabs and some with spaces (whcih I see all the time when a lot of people work on a file with different tools). To me, it just seems like a delicate system.
I've worked a little with python and I like the language, but the whitespace formatting still feels quite alien to me.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I'll provide at least one answer to what else you might be worried about - conflicts during checkin. But, like I said I usually only check in small sections (if anything) when working with files so it's not much of a problem.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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?)
nt
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
rage, rage against the dying of the light
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."
"He who questions training trains himself at asking questions." - The Sphinx, Mystery Men (1999)
Here here!
I have written applications, not scripts, full scale major applications in both python and in perl (amongst other languages). And I have found python to be an absolutely fantastic languauge, whilst my troubles with perl still continue. I'm sorry, but any language that you have to call with special flags to get it to give you warnings of any kind is kind of lame in my book. Also namespace is such a problem, major applications can easily become buggy because of a small namespace issues. This just doesn't happen in real languages that have sane scoping.
Perl is good at what it was originaly designed for. Practical Extraction and Report Language, but don't bother if you wan't a multithreaded TCP/IP server. (26 lines of python - including spaces). And to be honest, python is just as easy as perl at that to.
If you really beleive you have an 'investment' in perl then you need to get a life and become a real programmer. The only difference between most 3rd generation languages is syntax, and within a couple of weeks, and with a good reference (i.e. www.python.org) behind you you can pretty much do anything.
Everyone is living in a personal delusion, just some are more delusional than others.
Then so is the BSD license, which makes the non-advertising BSD license completely broken, since it doesn't accomplish the only thing it sets out to do.
There's an < missing between x and 10. That's what your C parser is picking up on.
-russ
Don't piss off The Angry Economist
No. There is no opportunity for acceptance or rejection. A contract *must* be accepted by both parties. All that's needed is to put the software inside a tarball, then to put it inside another tarball that contains "README" which offers the use of the software conditioned upon acceptance of the license. If you unpack the inner tarball, you have accepted the license. If you don't accept the license, you don't unpack the tarball. You may, if you wish, have a software agent which accepts the license for you. We can write a standard for the form of the license, so that in practice, you run "license" instead of "tar xfz". And you have pre-configured license with the licenses you will accept automatically.
RMS doesn't like this idea because the contract could specify terms of use, and he is unalterably opposed to any kind of use license (and I don't blame him). The solution is to oppose bad contracts, not to hide your head in the sand and pretend that users (not distributors) have disclaimed warranty.
I don't want to warrant use. Legally, right now, most of us do. This should be fixed.
-russ
Don't piss off The Angry Economist
Re-read it. That's not what he's saying. He's saying that privity -- and contract law -- is not necessary, because copyright law governs copying.
Note how the GPL says "This software is yours to use." That means that no conditions apply. It also means that the disclaimer of warranty (which requires agreement to a contract) does not apply to anyone who merely uses the software and refrains from copying it.
-russ
Don't piss off The Angry Economist
The GPL includes a warranty disclaimer. A warranty disclaimer is part of contract law. But the GPL is explicitly not a contract, but is instead a set of copyright permissions. So the warranty disclaimer doesn't apply to anyone who doesn't copy code.
The GPL warranty disclaimer can't work.
-russ
Don't piss off The Angry Economist
Your argument is just like saying, "the biggest problem that I face with java, is the portability of the code... it's extrememely difficult tow rite a "stand-alone" application that be distributed..." No CPU executes a java class file, for anyone to run your java program you need to have java installed, or give the the source. The same is true with python. Anyway, since most people have java VMs installed, another simpler way to accomplish this is to use Jython. Write in python, compile into javabyte code and just distribute the class files.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
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
Steven Rostedt
-- Nevermind
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
Steven Rostedt
-- Nevermind
There are some alternatives to freeze check: :)
This link.
Also, if that doesn't suit your needs, you could enhance it or write your own... I would sure appreciate it.
"Hey... don't be mean." --Buckaroo Banzai
Good point!
Moderate this up!
"Hey... don't be mean." --Buckaroo Banzai
And rejected 140 years ago, and "reaccepted" four years later, with a little friendly persuasion.
--
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
Guido van Rossum in a Nutshell
Is that anything like Prince Albert in a can?
--
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
Clearly!
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.
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.
...and it is not always obvious that is what's happening.
...or perhaps some pseudo code for the parser?
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.
Can we agree on a convention?
http://www.dictionary.com/cgi-bin/dict.pl?term=com monwealth
commonwealth \Com"mon*wealth`\ (?; 277), n. [Common + wealth well-being.] 1. A state; a body politic consisting of a certain number of men, united, by compact or tacit agreement, under one form of government and system of laws.
- - - - -
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Bullshit. If you can't understand, you don't even have middle-school reading comprehension skills. He said that it wasn't compatable, but that it would be with the removal of the choice of law clause. What is difficult to understand about that?
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!
--
assert(expired(knowledge));
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
-jacob
Absolutely. If you can't handle using character 13 rather than character 59 to end a statement and character 100 rather than character 123 to start a block, you'll be totally screwed when you see the way prolog does it.
--
-jacob
-jacob
Does everybody on slashdot think that the only salient feature of Python is that it doesn't use curly braces?
Get over it!
I am being quite serious. If that modest syntax change is enough to keep you from considering a language, you're doomed as a programmer to linguistic provencialism that will keep you from seeing some really elegant ways to simplify and modularize your code. Ever programmed in Erlang? Haskell? Scheme? Prolog? You might end up preferring a more mainstream language after all is said and done, but the experience of seeing the new ways of doing things will certainly make those mainstream programs better.
You'll never get that experience, though, if you get scared by the syntactic differences between those languages and C (which are vast). So do yourself a favor and try to see beyond a language's syntax.
--
-jacob
-jacob
Python:
Programming
the
way
Guido
indented
it
(Don't know if it was actually indented that way, but if it wasn't it should have been!)
What you say is true. Just because you have a firewall in place doesn't mean you can dispense with a root password on hosts behind your firewall.
"taint" mode is just another level of security to prevent obvious screwups.
It is good to see Python has likeminded protections.
The other way around this is to put you application on a web server and control the
...)
web server environment.
If you don't like coding against browser differences, then put as much logic as possible on the back end.
(For Java, use Servlets/JSP, for perl, use mod_perl
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein
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.
--
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
> Guido is a fairly discrete person, and it's
> always kinda difficult to know what he thinks
That's why I get the Big Bux to channel him.
> about functional programming
No secret: lambda, map(), filter() and reduce() were contributed code. He used to call them minor conveniences. Now he calls them minor annoyances, as they "opened the door" to people trying to use them as the foundation of a programming style Python wasn't designed to support. Guido still uses them himself as minor conveniences, but his brain isn't wired to use them for more than that. The point isn't theoretical purity (either pro or con), but plain effectiveness in practice for programmers of ordinary skill. List comprehensions (a la Haskell or SETL) were added much more recently, and on the latter basis: in the absence of dogmatic abuse, they're *clearer* than the loop-based alternatives. map() can be too, of course, but listcomps are even clearer than map. OTOH, I've never seen a Python program using reduce() that wasn't better written via a loop instead.
> typing
Yes, he types. I don't think he's even tried speech recognition yet .
> Python/Java complementarity or rivalry
Complementary. Indeed, the happiest Java programmers in the world may well be those who use Jython as a front end for prototyping, managing, exploring and testing their sprawling Java code. Java and Jython work very well together!
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_!
I have the same problem. Same with perl. PCs don't come with it, so I have to jump through hoops to get j.random luser to be able to run my utilities. The only answer for me so far is vanilla C, compiled by me for each platform I care about. I would *dearly* love it if Python (or perl, or java, or any language) could have a facility for compiling into a single native file (or at least a small collection of files) on many platforms (at least SGI,Sun,PC,Mac,Linux).
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
The Anti-Blog
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.
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.
as 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
Interesting, well I suppose I should compare the relative speakers, Guido versus a Guy who spends his life bending language and thought to sound the way he wants it too :-)
Jeremy
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
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.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
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.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Most assuredly, the funniest Monty Python was the milkman-psychiatrist. The subject matter is both self-referential and time-independent, so unlike most humor it becomes funnier because you know what is going to happen. Deja vu all over again.
Oracle and unix guy.
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.
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.
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
This isn't as much "normalization" as it is "don't take so many drugs when you're designing tables."
I was hoping for +1, Funny on the "parent" of this post, but oh well. "You can't...always get...what ya wa-ant!"
If you celebrate Xmas, befriend me (538
There's something wrong with the Slashdot's questions collecting system. Some of the questions that Guido has answered to were not very interesting, and better questions had been submitted by slashdot contributors. But, because they were not among the first to post their questions, they have not been moderated up, and thus their questions have not been picked.
There were many fascinating issues to discuss with Guido that have been completely missed. Things more relevant than "thoughts or Ruby?", "Favorite MP sketch?", etc... Guido is a fairly discrete person, and it's always kinda difficult to know what he thinks about functional programming, typing, Python/Java complementarity or rivalry, etc... This would have been a great occasion, and we missed it.
Was anyone else completely nonplussed by these answers? I'm not sure anything was said!
S.
Interestingly Perl won't allow you to do this either. Perl requires braces even around single statements following if, for, while, etc. So this is not a valid reason for Perl programmers to switch to Python.
--
Milk, it does a body good.
You find that disallowing a feature because it can't be implemented on a certain platform is a sign of thinking in terms of abstract language semantics?
Your second sentence contradicts the first.
BH
BH
Fools! They laughed at me at the Sorbonne...!
How about the following for Linux hackers:
or any other *shell for that matter. Which reminds--
Escher was the first MC and Giger invented the HR department.
Curious George
***General Consultant to the Human Race*** My opinions are free. You get what you pay for.
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
"Anybody who tells me I can't use a program because it's not open source, go suck on rms. I'm not interested." (LT 2004)
Well, there's your problem. Tabs are just evil; don't ever use tabs in your code. :) I have my tab key set to insert 4 space characters, if I ever really need a hard tab (like in a makefile), I hit ctrl-tab.
Well, http://www.commonwealth.va.us is 404... really they should have that, for the purists among us.
sulli
RTFJ.
Well, Virginia is a Commonwealth, as any Virginian knows, so that might be part of the problem!
sulli
RTFJ.
The indentation blocking is a shame if only because it's so much of a distraction in discussing the language. I don't know much about python and was hoping to learn why it's useful here, but just about all I gleaned from these comments is that the blocking is controversial and the license is in a legal quagmire.
So aside from all that, why should I use python?
_ The bureaucracy is expanding to meet
_ The bureaucracy is expanding to meet
the needs of an expanding bureaucracy.
My project, SUBTERFUGUE, 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
"Not an actor, but he plays one on TV."
Everyone likes to talk about the whitespace... how do you explain the multiple underscores!!!!
Yuck!
Interactive Visual Medical Dictionary
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.
I'm still trying to figure out what people mean by 'social skills' here.
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
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
Got a full tank of hot grits and a penis bird in the glove box.
No we don't.
The only certainty is entropy.
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
if 'fruits de mer' = seafood
does 'fruits de merde' = mushrooms?
Well... perl -T doesn't offer any sort of guarantees. It's not perfect (as bug fixes to taint mode over time will attest) and can (intentionally or accidentally) be bypassed using the documented laundering techniques. That's not to say that the taint mechanism is not useful -- it is a help -- but one must take care not to be lulled into a false sense of security in its capabilities.
With all those qualifiers out of the way: yes, Python does try to solve simliar problems with its bundled rexec and Bastion modules. Again, this should not be seen as a magic bullet! With enough effort, people can accomplish stupid things in any environment.
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!
dave
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.
I used to have a sig, but I set it free and it never came back.
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!
> Please take a deep breath and go in for one last go-around with the FSF lawyers. Pretty please?
Why? the FSF position seems to be "we're happy to compromise, as soon as you do it our way" and "we won't tell you how to fix it, just that it's wrong. Keep guessing"
When will the FSF start working with these groups, instead of simply demanding everyone do it their way or else?
Chuq Von Rospach, Internet Gnome = When his IQ reaches 50, he should sell
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.
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!'
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.
Indeed.