Posted by
Hemos
on from the wrapping-itself-around-the-world dept.
tonys1110 was one of the first to tell us that Python[?] 1.6 Final has been released unto the world. They've got a bit about the license, and of course, the obligatory "What's New".
This is great news! Python is my favorite programming language to date. It all of my favorite features that are in other languages.
For those of you that don't know much about python, I would encourage you to try it out! Coming from the following languages, here is why I would recommend python:
Java - Python has a class library the size of Java's, its VM starts up faster, and its simpler to write and maintain. Plus, it isn't controlled by Sun!
Perl - Okay, all religious issues aside here. Get real. Perl is a great language, but it has largely been extended beyond its original intent, and is straining to keep up. Python is easier to learn, develop in, and most of all *maintain*. If you have ever looked at another person's Perl code and tried to maintain it, you know what I mean. Perl is cool. Python is cooler. Give it a shot, you can even use Perl style regular expressions!
C++ - Still haven't realized that C++ is a dirty hack eh? No, all kidding aside, C++ is also a great language. Honestly though, I struggle to develop quickly in C++ because I keep running into language barriers. C++ is probably the most widely used OO language next to Java. I for one am sick of managing my own memory. Leave it to the garbage collector thanks =) If you want a really really fast OO application, write it in C++. If you want to develop a OO application really really fast -- choose Python.
C - Ahh, the great C. What a fantastic language. Fast, Fast, Fast! But, not object oriented. Now, I know in the Linux world there are a lot of C lovers, and don't get me wrong, C has many uses. But the world would benefit if people would write their apps in Python. There would be very few memory related bugs! Many times, the development cycle is slowed dramatically by C's tragically painful memory management. Programmers are dumb. We really are. We make silly off by 1 errors, that oftentimes can make a C program leak memory like a swiss cheese bucket. Write in Python. Its *so* much easier, and is perfectly fast for GUIs, and many server applications.
Python, to me, is the language of the future. It is fast, easy to lean, fun to develop in, and is just plain cool.
If you have ever looked at another person's Perl code and tried to maintain it, you know what I mean.
Wow, what a common misconception. I can write unmaintainable code in any language, and maintainable code in any language. I've seen beautiful perl code readable like plain enlgish and I've seen perl code so bad, it looked like it was run through a blender. But the same can be said for python; bad code can be written in every language. The key issue is the abuse of syntactic features, either through overuse or underuse.
The great thing is almost every language has a single syntactic element that makes every other line of code perfectly readable when used; it is called the comment. I suggest sprinkling it throughout code in any language.
Now, don't get me wrong, I don't have anything at all against python; I just don't like to see people say misleading things about perl.
And BTW, C++ is not an object oriented language--it is a hybrid language. An examle of a real OO language would be Smalltalk.
Below, I refer to Java and Python together. Why? They are very similar in the way they think of classes, objects, and complex datatypes in general.
Objective C is as close as you're going to get. There are always trade-offs: C++ is probably the fastest object oriented language out there (unless you plan to use typedefs a whole lot in C). C++ is also the most restricting object oriented language I can think of. Why? Several reasons, usually relating to C++ wanting to be more efficient. Example: Unlike Python and Java, C++ does not have a sense of a "class type" -- a class only exists at a source code level -- at runtime, it fails to exist. Unlike Java and Python, you can't pass a class as an object or look at it in runtime.
Objective C is a more of a mix. It doesn't have the slickness of automatic references or the safety of Java/Python, but it isn't as irrational and preprocessor dependant as C++. It's all in trade-offs, but I think Objective C might have the right set of trade-offs you want.
In relation Python? Python's another set of trade-offs: nice since of classes/objects, reasonably efficient for many purposes, a clean syntax, and slick string processing. It's the best of all languages, or depending on your point of view, the worst.:)
-- --
Ken Kinder
ken@_nospam_kenkinder.com
http://kenkinder.com/
Re:Speed of Languages is Often Discussed
by
nd
·
· Score: 2
for i in range(2,endp):
for j in range(2,i):
I think it's bad to use range() in tight algorithms like this. It gives Python a unnecessary disadvantage here (I think because it has to keep rebuilding that list/tuple 10000 times whereas in your C algorithm it's only done once (well, not at all really).) You should consider either make it do it only once or use something like xrange()
Re:When is Python getting an optimizing compiler?
by
William+Tanksley
·
· Score: 2
Yes, it can do SWING calls. It can call arbitrary Java code. Interestingly, it also correctly handles Python's multiple inheritance.
Python is probably pretty much like Perl/{Tk,GTK} for rapid-protyping, though I don't really know as I don't use Perl:/ That said, I've been able to create some usefull Python scripts in a relatively short time. Also, due to it's interactive interface, it comes in handy when you need to do some quick calculations and bc or dc seem to be too much bother.
Bill - aka taniwha --
--
Bill - aka taniwha -- Leave others their otherness. -- Aratak
Plus the error messages in awk are so much more charming. I defy anyone to quote an error message more evocative than "Awk: bailing out near line 1."
-- Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Then use something different!
by
mholve
·
· Score: 2
There are a LOT of languages out there - many suited to a particular application. If one doesn't suit you - use another, if possible.
Although I certainly agree with you - forced coding styles are kinda slack, but do enforce a standard and might make debugging or maintaining someone else's code a LOT easier!
So why not dual license, e.g. GPL for linking with GPL'd code and artistic or BSD?
-- Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Whats so amazing? perl does all this
by
Ars-Fartsica
·
· Score: 2
For instance, you do not need to qualify variables in any way ( not event with the pre-pended special characters Perl uses).
There is a reason perl does this - it allows you to have different types of variables in the same namespace.
@t
and
$t
can be placed beside each other in a perl program - one is an array, one is a scalar, although they have the same name. Look up perl's type globs to see why you would want to do this. It is occasionally very useful and powerful.
And you can assign an integer to
the same variable which until then contained a string. This is a bonus for fast prototyping
Perl scalars can do this easily, and perl operators know how to manipulate data automagically, inferred from the type of data you assign to a scalar, without qualification.
What's Python?
by
Anonymous Coward
·
· Score: 2
You Python/Perl weenies. I can do anything you can in awk.
Re:What's Python?
by
Anonymous Coward
·
· Score: 2
After reading some of the info regarding the new Python release I see that they've decided to release 1.6 under an open source license that they believe to be compatible with GPL, although it seems RMS disagrees. This is the second item today that I've seen that has potential licensing woes.
Why is it that we need to many different licenses? If the concern is to be GPL compatible then why not release under the GPL?
It seems to be an important task to iron out the major differences between the most popular licenses and get everybody under one legal roof in case problems start to develop. I doubt we have the legal resources to create and defend rigorously 7 types of licenses.
Heh a closed source commercial app modifies an GPL'd app.. you just violated your lic if you didnt release the code which most people dont want to do nor are they going to.
The root of the problem, currently, is that the license defines the legal domain it must be challenged in.
Which is to say that if there is going to be legal action taken, it must be taken in the state of Virginia, as defined by the CNRI Python license. You can't challenge it without going to Virginia, and if you are challenged, it will by by the laws of Virginia.
*THE REASONING* behind this is that without specifying who's laws apply, inevitably someone will challenge it in the least restrictive venue possible: ie. a venue in which the GPL can't be enforced *at all*.
CNRI makes a good point, and RMS will probably be forced to finally admit that he's made a mistake.
The Python 1.6 License FAQ may clarify some of these issues for you. CNRI owns the code that Guido and I and our co-workers wrote at CNRI -- and they have decided to release Python 1.6 with a license that RMS has an issue with.
The specific issue is that RMS believes that the clause in the Python license that says the contract is governed by the laws of Virginia is incompatible. The lawyers are still working on this one...
We are doing a lot of work at BeOpen with CNRI to get them to allow
the GPL as an alternative license across the CNRI-derived parts of the
codebase. Bob Kahn of CNRI seems to dislike the GPL so he has been against
doing this as part of a CNRI release but potentially has been amenable to
allowing it to be done by BeOpen in a derivative release. We shall see in
the next week whether or not this is true and will let everyone know how
it goes. We at BeOpen want GPL-compatibility and have pushed for that since
we started with any Python licensing issues.
Being free software, it seems, isn't enough for RMS. After all he didn't dispute that QPL was free.
LGPL and BSD aren't afflicted with the curse of viral GPL. Since switching to GPL doesn't protect you from RMS's legal threats any more, I suggest ditching viral GPL altogether is the path of least resistance.
So? Link dynamicly. Also, the GPL doesn't prevent you from charging for the product. In fact, the old Python license actually did prevent people from making money. Going pure GPL (or LGPL) would give more freedom than the old Python license.
Bill - aka taniwha --
--
Bill - aka taniwha -- Leave others their otherness. -- Aratak
What it comes down to is that some people think GPL too restrictive. Python, for example, can be included in proprietary software, similarly to BSD but does have some restrictions BSD doesn't. What I don't understand is why this is suddenly getting all this press? The Python 1.5 license had similar GPL compatibility problems and it didn't stop anyone from using it. Python, is most certainly, free software.
-- --
Ken Kinder
ken@_nospam_kenkinder.com
http://kenkinder.com/
I don't normally play the silly Python -vs- Perl games, but the AC has a valid point.
Python is really just an academic toy. Real world scripting requires a fast, loose, flexible approach, which is totally absent in Python. Forcing people into using strict grammar and structure may be a good teaching tool, but it has little application in getting things done on schedule.
Re:Licensing problems == UCITA
by
rjh3
·
· Score: 2
There will be a problem with any license, even near duplicates of the GPL, if the applicable state law includes UCITA. Right now, this means Virginia and Maryland, with Iowa close behind them. Why? Because UCITA permits unilateral and unlimited modification of the license terms. Just because it is GPL today does not mean it is GPL tomorrow. An email notification attempt followed by a brief wait is all it takes to change a GPL'ed program into a proprietary program.
Things get far more complex as the author count increases and the variety of potentially applicable state laws increase. But UCITA rules on the original license will probably be held to flow through to all the derivative works.
So a change of management can take the best of organizations with perfect GPL intentions and convert it into proprietary software.
not the old "stifling creativity" thing again...
by
tuffy
·
· Score: 2
I think Perl stifles my creativity by forcing me to put {}brackets around my code blocks. And C stifles my creativity by not allowing me to use keywords as variable names. And Lisp stifles my creativity by forcing me to use parentheses.
Oh please do get over it. If your creativity is entirely dependant upon a certain style of language syntax, perhaps you'd best take up maintaining old COBOL code and leave the programming to those who are beyond such trivialities.
--
Ita erat quando hic adveni.
Re:Python stifles creativity
by
redhog
·
· Score: 2
Except if what you are to do in schedule is debugging:)
I don't want to debug/maintain someone else's perl-code.
Does quick-and-durty mean anything to you?
-- --The knowledge that you are an idiot, is what distinguishes you from one.
Python r2.0 is on its way, coming soon to a [BeOpen] site near you.
Among its other features, as listed in a [What's New] doc, are:
Unicode.
List comprehensions (automagic list looping).
Augmented assignment (+= syntactic sugar).
New string methods.
Improved GC.
Several new functions.
Comprehensive XML libraries.
HTTP1.1 support.
Improved curses support.
SSL support.
A new regular expression parser (Unicode-compatible).
Improved IDE.
Re:Speed of Languages is Often Discussed
by
FFFish
·
· Score: 2
Not shit, Sherlock!
Python is *interpreted*.
C is *compiled*.
And any halfwit knows that the key to having blazingly fast Python apps is to write them in Python (blazingly fast development), profile them, and then rewrite the slow bits in C (blazingly fast execution).
I suppose your next trick will be to test Javascript against assembly code!
--
--
--
Don't like it? Respond with words, not karma.
Re:Speed of Languages is Often Discussed
by
kjz
·
· Score: 4
Althought the algorithm used in the above two programs is the same, the specific semantics are different. In the Python program above, you are using global variables. The C implementation of Python is notoriously slow in looking up global variables. In addition, the range() function allocates an array of values, as other posters have pointed out.
I wrote a version of your program which uses xrange() and saw a significant performance increase:
#!/usr/local/bin/python
endp = 10000;
totl = 0
for i in xrange(2,endp):
for j in xrange(2,i):
if i%j == 0:
break
else:
totl = totl + 1
print totl, 'prime numbers between 1 and', endp
Your original script on my machine produced the following (yes, I'm running on W2K; I'm at work. *sigh*):
[//c/Projects/Scripts] time python primes_orig.py
1229 prime numbers between 1 and 10000
real 0m10.215s
user 0m0.010s
sys 0m0.040s
The new script above produced:
[//c/Projects/Scripts] time python primes_xrange.py
1229 prime numbers between 1 and 10000
real 0m6.980s
user 0m0.010s
sys 0m0.000s
I was further able to shave another 1.4s off that time by moving everything into a function:
#!/usr/local/bin/python
def getprimes(endp):
totl = 0
for i in xrange(2,endp):
for j in xrange(2,i):
if i%j == 0:
break
else:
totl = totl + 1
return totl
max = 10000
print getprimes(max), 'prime numbers between 1 and', max
This resulted in:
[//c/Projects/Scripts] time python primes_new.py
1229 prime numbers between 1 and 10000
real 0m5.578s
user 0m0.010s
sys 0m0.000s
I'm sure that the real Python gurus can do a whole lot better. You can always post to comp.lang.python and get some truly outstanding help there. It's one of the few remaining civil newsgroups left on Usenet (in my opinion, of course).
Keep in mind, though, that benchmarks like these don't tell you the whole story. For one thing, consider how much more a developer's time will cost you compared to the extra processing time. A good Python programmer will, in many cases, crank out a program in a fraction of the time that a good C programmer will take. This will vary from programmer to programmer, of course, but I have found that to hold true in my particular case.
As a former Red Hatter, let me offer some clarification on this.
First of all, just becuase something is GNOME-aware (or even uses GTK+ as its widget set) does not exclude Python as its programming language. There's PyGNOME and PyGTK which provide excellent bindings to GNOME and GTK, respectively, for those who wish to write GNOME- and GTK-aware programs in Python. (The Red Hat installer, Anaconda, which uses GTK is written in Python, for example.)
The Red Hat utilities, I believe, that you are referring to (netcfg, printtool, control-panel, timetool, etc.) are old and were, at the time, "quick-hacks" to enable GUI configuration of common services to newer users. Last I heard, Red Hat planned to work on/contribute to newer tool that fit into the GNOME framework to perform those same actions. I have no idea whether or not they would be coded in Python.
As far as what Red Hat believes to be the roles of various languages to be is their call, but while I was there, there was the belief that the strengths of various languages make them better suited for some tasks and lesser suieted for others.
I believe it combines the expressiveness of Perl with the clarity of Python.
Ruby is easier to read than Perl because it has been designed as an OOP language from the grounds-up. You also won't see stuff like @{$foo->['bar']} (is that right ?) but instead Ruby uses simple naming conventions to denote the scope of variables. Examples: simple 'var' = local variable, '@var' = instance variable, '$var' = global variable.
And I prefer Ruby to Python because Ruby has assignment syntax sugar such as +=, -=, etc. and all data (including Integer, String, List, etc.) in Ruby are class instances.
For instance, you do not need to qualify variables in any way ( not event with the pre-pended special characters Perl uses).
Personally, I think that's a beneficial feature. You can tell whether something is a variable or an array of values, and it removes absolutely any conflict between variable names and language keywords.
Re:Python stifles creativity
by
Panix
·
· Score: 2
I could not disagree any more on this point. *EVERY* language enforces a set of rules. Look at C for instance, each block *must* be enclosed in braces! You have to use certain kinds of variable names (specifically, you cannot start a variable identifier with a dollar sign for example).
Your argument simply does not hold water. Python allows an equal amount of creativity to any other language, and places an equal number of restrictions on the programmer. I hated the Python indentation syntax for about 20 minutes. And then it seemed very natural to me. On top of that, my code was more readable, and so was others!
Think about poetry. There are many different kinds of poetry, and most of them enforce a certain structure. Sonnets for example. These restrictions are not in place to hamper the creative expression of the author, but to allow the author to work within a common set of restrictions, so others may better understand his expressions.
Using your argument, I could claim that Punctuation stifles my creativity, and simply write every sentence in this comment without any. Now, that may be creative, but it would certainly prevent my comment from being very readable, or understandable.
Python is great, I really suggest that you get over your minimal objections, and give it another shot.
I am serious sick of hearing that every license in the world does not confirm to the GPL. Is this just me? Please, please, for the sake of mankind, would you guys please stop. I use to love free software and open source prior to it's popularity. There was no politics, and even if there was, it wasn't serious. I don't come to slashdot to become depressed, but to be enlightened.
-- ------
Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
I take it that it's not too much unlike Perl/Tk or Perl/GTK in the rapid-prototyping sense?
IMO, python is better for rapid prototyping, because of is more dynamic than Perl, it gives more freedom to the programmers and and has a less encumbered syntax.
For instance, you do not need to qualify variables in any way ( not event with the pre-pended special characters Perl uses). And you can assign an integer to the same variable which until then
contained a string. This is a bonus for fast prototyping , altough it might lead to troubles in
in the hands of bad programmers ( but the same might be said of many features of more constrained
languages ).
Python is also better in doing Object Oriented stuff - in this is even better than C++ ( not that it takes much ), and as good as Java.
The drawback is that you pay all this in performance. But for several classes of application, this is not an issue.
And Python is incredibly easy to learn. Give it a try!
Sorry for the sermon, but I quite like Python.
-- Ciao
----
FB
Speed of Languages is Often Discussed
by
mog
·
· Score: 2
But it's rare to see benchmarks giving clear data as far as speed goes. These are very informal tests, but for identical algorithms (prime number finder) in Python VS C.. C blows Python out of the water. Much more so than I would have thought (I'm a fan of both Python and C). The source to the two (small) programs will be attached to this post (to save space on the main thread).
[c code]
1229 prime numbers between 1 and 10000
real 0m0.706s
user 0m0.703s
sys 0m0.003s
[python code]
[alex@csc ~/prog/python/trial]$ time./grab.py
1229 prime numbers between 1 and 10000
In other news, the developers of Python have just received a letter from Digital Convergence demanding that they cease and desist making a "device capable of infringing on our IP." Company CEO J. Jovian Philyaw comments: "We really like the open source community, but if we don't defend our IP, we'll lose it! Because programs can be written in Python which utilize our IP, we must put a stop to the language." Unnamed members of the open source community responded with a quote which is not printable but which involved anatomically improbable actions involving goats.
Note: The above is facetious and non factual. Except maybe the bit about the goats.
--
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Re:Python stifles creativity
by
drinkypoo
·
· Score: 2
Well, I'm sorry, but I will NEVER be able to consider an interpreted language useful for writing "real" applications. If it won't compile then it's just a scripting tool.
dictionary.com strikes again:
application is defined, in the American Heritage Dictionary, in the following fashion: "Of or being a computer program designed for a specific task or use: applications software for a missile guidance system."
In other words any program you have written for any specific purpose is an application. This includes my ~25 line perl script which does nothing but check to make sure email addresses are something like valid, and prints them to an output file if they are, and doesn't if they're not. It's not exactly complex, but it is, technically, an application.
It gets even better when you use the definition from WordNet: 3: a program that gives a computer instructions that provide the user with tools to accomplish a task; "he has tried several different word processing applications" [syn: application program, application s programme]. This could be something as trivial as a script which echoes something to the screen, like the date and time. How many lines of perl does that take if you only do one semicolon per line?
Finally, as listed in the above-linked application program is the following segment of definition: " (Or "application", "app") A complete, self-contained program that performs a specific function directly for the user." It also says that One distinction between an application program and the operating system is that applications always run in "user mode" (or "non-privileged mode"), while operating systems and related utilities may run in "supervisor mode" (or "privileged mode").
I hope this clears up somewhat what an application is. If there are any other words you don't understand in this post, please use dictionary.com to clear things up. It will save you the embarrassment and me the trouble of the tedium of your correction.
-- "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Python 2.0b1 also due out today
by
Corvus
·
· Score: 5
Slashdot Mirror
This is great news! Python is my favorite programming language to date. It all of my favorite features that are in other languages.
For those of you that don't know much about python, I would encourage you to try it out! Coming from the following languages, here is why I would recommend python:
Java - Python has a class library the size of Java's, its VM starts up faster, and its simpler to write and maintain. Plus, it isn't controlled by Sun!
Perl - Okay, all religious issues aside here. Get real. Perl is a great language, but it has largely been extended beyond its original intent, and is straining to keep up. Python is easier to learn, develop in, and most of all *maintain*. If you have ever looked at another person's Perl code and tried to maintain it, you know what I mean. Perl is cool. Python is cooler. Give it a shot, you can even use Perl style regular expressions!
C++ - Still haven't realized that C++ is a dirty hack eh? No, all kidding aside, C++ is also a great language. Honestly though, I struggle to develop quickly in C++ because I keep running into language barriers. C++ is probably the most widely used OO language next to Java. I for one am sick of managing my own memory. Leave it to the garbage collector thanks =) If you want a really really fast OO application, write it in C++. If you want to develop a OO application really really fast -- choose Python.
C - Ahh, the great C. What a fantastic language. Fast, Fast, Fast! But, not object oriented. Now, I know in the Linux world there are a lot of C lovers, and don't get me wrong, C has many uses. But the world would benefit if people would write their apps in Python. There would be very few memory related bugs! Many times, the development cycle is slowed dramatically by C's tragically painful memory management. Programmers are dumb. We really are. We make silly off by 1 errors, that oftentimes can make a C program leak memory like a swiss cheese bucket. Write in Python. Its *so* much easier, and is perfectly fast for GUIs, and many server applications.
Python, to me, is the language of the future. It is fast, easy to lean, fun to develop in, and is just plain cool.
for i in range(2,endp):
for j in range(2,i):
I think it's bad to use range() in tight algorithms like this. It gives Python a unnecessary disadvantage here (I think because it has to keep rebuilding that list/tuple 10000 times whereas in your C algorithm it's only done once (well, not at all really).) You should consider either make it do it only once or use something like xrange()
Yes, it can do SWING calls. It can call arbitrary Java code. Interestingly, it also correctly handles Python's multiple inheritance.
-Billy
Bill - aka taniwha
--
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
Plus the error messages in awk are so much more charming. I defy anyone to quote an error message more evocative than "Awk: bailing out near line 1."
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Although I certainly agree with you - forced coding styles are kinda slack, but do enforce a standard and might make debugging or maintaining someone else's code a LOT easier!
So why not dual license, e.g. GPL for linking with GPL'd code and artistic or BSD?
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
There is a reason perl does this - it allows you to have different types of variables in the same namespace.
@t
and
$t
can be placed beside each other in a perl program - one is an array, one is a scalar, although they have the same name. Look up perl's type globs to see why you would want to do this. It is occasionally very useful and powerful.
And you can assign an integer to the same variable which until then contained a string. This is a bonus for fast prototyping
Perl scalars can do this easily, and perl operators know how to manipulate data automagically, inferred from the type of data you assign to a scalar, without qualification.
You Python/Perl weenies. I can do anything you can in awk.
After reading some of the info regarding the new Python release I see that they've decided to release 1.6 under an open source license that they believe to be compatible with GPL, although it seems RMS disagrees. This is the second item today that I've seen that has potential licensing woes.
Why is it that we need to many different licenses? If the concern is to be GPL compatible then why not release under the GPL?
It seems to be an important task to iron out the major differences between the most popular licenses and get everybody under one legal roof in case problems start to develop. I doubt we have the legal resources to create and defend rigorously 7 types of licenses.
What it reminds me most of is Lisp, but with indents instead of parentheses.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Python is really just an academic toy. Real world scripting requires a fast, loose, flexible approach, which is totally absent in Python. Forcing people into using strict grammar and structure may be a good teaching tool, but it has little application in getting things done on schedule.
There will be a problem with any license, even near duplicates of the GPL, if the applicable state law includes UCITA. Right now, this means Virginia and Maryland, with Iowa close behind them. Why? Because UCITA permits unilateral and unlimited modification of the license terms. Just because it is GPL today does not mean it is GPL tomorrow. An email notification attempt followed by a brief wait is all it takes to change a GPL'ed program into a proprietary program.
Things get far more complex as the author count increases and the variety of potentially applicable state laws increase. But UCITA rules on the original license will probably be held to flow through to all the derivative works.
So a change of management can take the best of organizations with perfect GPL intentions and convert it into proprietary software.
Oh please do get over it. If your creativity is entirely dependant upon a certain style of language syntax, perhaps you'd best take up maintaining old COBOL code and leave the programming to those who are beyond such trivialities.
Ita erat quando hic adveni.
Except if what you are to do in schedule is debugging :)
I don't want to debug/maintain someone else's perl-code.
Does quick-and-durty mean anything to you?
--The knowledge that you are an idiot, is what distinguishes you from one.
Python r2.0 is on its way, coming soon to a [BeOpen] site near you.
Among its other features, as listed in a [What's New] doc, are:
Unicode.
List comprehensions (automagic list looping).
Augmented assignment (+= syntactic sugar).
New string methods.
Improved GC.
Several new functions.
Comprehensive XML libraries.
HTTP1.1 support.
Improved curses support.
SSL support.
A new regular expression parser (Unicode-compatible).
Improved IDE.
And other things you can go [read for yourself].
--
--
Don't like it? Respond with words, not karma.
Not shit, Sherlock!
Python is *interpreted*.
C is *compiled*.
And any halfwit knows that the key to having blazingly fast Python apps is to write them in Python (blazingly fast development), profile them, and then rewrite the slow bits in C (blazingly fast execution).
I suppose your next trick will be to test Javascript against assembly code!
--
--
Don't like it? Respond with words, not karma.
Althought the algorithm used in the above two programs is the same, the specific semantics are different. In the Python program above, you are using global variables. The C implementation of Python is notoriously slow in looking up global variables. In addition, the range() function allocates an array of values, as other posters have pointed out.
I wrote a version of your program which uses xrange() and saw a significant performance increase:
#!/usr/local/bin/python
endp = 10000;
totl = 0
for i in xrange(2,endp):
for j in xrange(2,i):
if i%j == 0:
break
else:
totl = totl + 1
print totl, 'prime numbers between 1 and', endp
Your original script on my machine produced the following (yes, I'm running on W2K; I'm at work. *sigh*):
[//c/Projects/Scripts] time python primes_orig.py
1229 prime numbers between 1 and 10000
real 0m10.215s
user 0m0.010s
sys 0m0.040s
The new script above produced:
[//c/Projects/Scripts] time python primes_xrange.py
1229 prime numbers between 1 and 10000
real 0m6.980s
user 0m0.010s
sys 0m0.000s
I was further able to shave another 1.4s off that time by moving everything into a function:
#!/usr/local/bin/python
def getprimes(endp):
totl = 0
for i in xrange(2,endp):
for j in xrange(2,i):
if i%j == 0:
break
else:
totl = totl + 1
return totl
max = 10000
print getprimes(max), 'prime numbers between 1 and', max
This resulted in:
[//c/Projects/Scripts] time python primes_new.py
1229 prime numbers between 1 and 10000
real 0m5.578s
user 0m0.010s
sys 0m0.000s
I'm sure that the real Python gurus can do a whole lot better. You can always post to comp.lang.python and get some truly outstanding help there. It's one of the few remaining civil newsgroups left on Usenet (in my opinion, of course).
Keep in mind, though, that benchmarks like these don't tell you the whole story. For one thing, consider how much more a developer's time will cost you compared to the extra processing time. A good Python programmer will, in many cases, crank out a program in a fraction of the time that a good C programmer will take. This will vary from programmer to programmer, of course, but I have found that to hold true in my particular case.
-kjz
As a former Red Hatter, let me offer some clarification on this.
First of all, just becuase something is GNOME-aware (or even uses GTK+ as its widget set) does not exclude Python as its programming language. There's PyGNOME and PyGTK which provide excellent bindings to GNOME and GTK, respectively, for those who wish to write GNOME- and GTK-aware programs in Python. (The Red Hat installer, Anaconda, which uses GTK is written in Python, for example.)
The Red Hat utilities, I believe, that you are referring to (netcfg, printtool, control-panel, timetool, etc.) are old and were, at the time, "quick-hacks" to enable GUI configuration of common services to newer users. Last I heard, Red Hat planned to work on/contribute to newer tool that fit into the GNOME framework to perform those same actions. I have no idea whether or not they would be coded in Python.
As far as what Red Hat believes to be the roles of various languages to be is their call, but while I was there, there was the belief that the strengths of various languages make them better suited for some tasks and lesser suieted for others.
Ken
Ruby is easier to read than Perl because it has been designed as an OOP language from the grounds-up. You also won't see stuff like @{$foo->['bar']} (is that right ?) but instead Ruby uses simple naming conventions to denote the scope of variables. Examples: simple 'var' = local variable, '@var' = instance variable, '$var' = global variable.
And I prefer Ruby to Python because Ruby has assignment syntax sugar such as +=, -=, etc. and all data (including Integer, String, List, etc.) in Ruby are class instances.
Anyway, for a better overview of Ruby, look at: The Ruby Home Page
See my related post on this!
Personally, I think that's a beneficial feature. You can tell whether something is a variable or an array of values, and it removes absolutely any conflict between variable names and language keywords.
I could not disagree any more on this point. *EVERY* language enforces a set of rules. Look at C for instance, each block *must* be enclosed in braces! You have to use certain kinds of variable names (specifically, you cannot start a variable identifier with a dollar sign for example).
Your argument simply does not hold water. Python allows an equal amount of creativity to any other language, and places an equal number of restrictions on the programmer. I hated the Python indentation syntax for about 20 minutes. And then it seemed very natural to me. On top of that, my code was more readable, and so was others!
Think about poetry. There are many different kinds of poetry, and most of them enforce a certain structure. Sonnets for example. These restrictions are not in place to hamper the creative expression of the author, but to allow the author to work within a common set of restrictions, so others may better understand his expressions.
Using your argument, I could claim that Punctuation stifles my creativity, and simply write every sentence in this comment without any. Now, that may be creative, but it would certainly prevent my comment from being very readable, or understandable.
Python is great, I really suggest that you get over your minimal objections, and give it another shot.
I am serious sick of hearing that every license in the world does not confirm to the GPL. Is this just me? Please, please, for the sake of mankind, would you guys please stop. I use to love free software and open source prior to it's popularity. There was no politics, and even if there was, it wasn't serious. I don't come to slashdot to become depressed, but to be enlightened.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
How long will it take
for the Python versus Perl
idiots to post
love,
br4dh4x0r
IMO, python is better for rapid prototyping, because of is more dynamic than Perl, it gives more freedom to the programmers and and has a less encumbered syntax.
For instance, you do not need to qualify variables in any way ( not event with the pre-pended special characters Perl uses). And you can assign an integer to the same variable which until then contained a string. This is a bonus for fast prototyping , altough it might lead to troubles in in the hands of bad programmers ( but the same might be said of many features of more constrained languages ).
Python is also better in doing Object Oriented stuff - in this is even better than C++ ( not that it takes much ), and as good as Java.
The drawback is that you pay all this in performance. But for several classes of application, this is not an issue.
And Python is incredibly easy to learn. Give it a try!
Sorry for the sermon, but I quite like Python.
Ciao
----
FB
But it's rare to see benchmarks giving clear data as far as speed goes. These are very informal tests, but for identical algorithms (prime number finder) in Python VS C.. C blows Python out of the water. Much more so than I would have thought (I'm a fan of both Python and C). The source to the two (small) programs will be attached to this post (to save space on the main thread).
./grab.py
[c code]
1229 prime numbers between 1 and 10000
real 0m0.706s
user 0m0.703s
sys 0m0.003s
[python code]
[alex@csc ~/prog/python/trial]$ time
1229 prime numbers between 1 and 10000
real 0m40.362s
user 0m40.138s
sys 0m0.198s
Note: The above is facetious and non factual. Except maybe the bit about the goats.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
dictionary.com strikes again:
application is defined, in the American Heritage Dictionary, in the following fashion: "Of or being a computer program designed for a specific task or use: applications software for a missile guidance system."
In other words any program you have written for any specific purpose is an application. This includes my ~25 line perl script which does nothing but check to make sure email addresses are something like valid, and prints them to an output file if they are, and doesn't if they're not. It's not exactly complex, but it is, technically, an application.
It gets even better when you use the definition from WordNet: 3: a program that gives a computer instructions that provide the user with tools to accomplish a task; "he has tried several different word processing applications" [syn: application program, application s programme]. This could be something as trivial as a script which echoes something to the screen, like the date and time. How many lines of perl does that take if you only do one semicolon per line?
Finally, as listed in the above-linked application program is the following segment of definition: " (Or "application", "app") A complete, self-contained program that performs a specific function directly for the user." It also says that One distinction between an application program and the operating system is that applications always run in "user mode" (or "non-privileged mode"), while operating systems and related utilities may run in "supervisor mode" (or "privileged mode").
I hope this clears up somewhat what an application is. If there are any other words you don't understand in this post, please use dictionary.com to clear things up. It will save you the embarrassment and me the trouble of the tedium of your correction.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
That is all.