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.
Other peoples' perl code is not so bad when they follow good programming practice. I write perl like C, and it ends up being very readable by other humans.
-- "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
I'm tired of hearing Perl programmers whine about how "Perl doesn't write unreadable programs, programmers do." Stereotypes may be stereotypes, but they don't come from nowhere. This defense makes me wonder why it is Perl seems to draw so many bad programmers.
Not to knock Perl; I compare it to English. A mishmash of syntax, but very effective and capable of expressing complexity succinctly and cleverly. What makes Perl bad is the power it grants to use inconsistent/confusing syntax and programming style. There's More Than One Way To Do It means that you did it differently from me and I'm going to waste time figuring out why if I ever look at your code. Sure, you can write clean, tidy Perl code, but if you're going to all that trouble you're not taking full advantage of the flexibility of the language, so why the heck are you writing in Perl anyways? Better off using Python, which not only allows you to write nice code but does a much better job of enforcing it.
- Don't you hate it when people use reverse psychology to get moderated up? I'll just tell ya': moderate me up all you want!
--
"If you look 'round the table and can't tell who the sucker is, it's you." -- Quiz Show
Off-by-one errors in C? Maybe you do,
but don't speak for the rest of us... In the last 4500 lines I've written (my current project), I've had maybe three errors like that which caused memory problems... of which, they each took maybe 20 minutes to fix. Massive productivity stopper? Don't think so.
Yes, actually. The software company I work for develops almost 100% in Python. Once you learn the basics of Python and how its C extensions work, its actually truly simple.
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/
I really wish someone would create a "fixed" C/C++. New sorts of languages like Java, Perl, etc. are all nice, but what I'd really like is a systems language mostly like C++, but with all the problems fixed.
There are so many really cool things you could do to make C++ an easier language without sacrificing power if you just bailed on backwards compatibility. I'd like a language pretty much like C++ in general, but with things like arrays that are bounds checked and built-in strings.
It annoys me that when there are so many widely acknowledged annoyances in C/C++, that people keep creating "successors" to C/C++ that simply don't fill the same niche. Java/Perl/Python all have their place, but they it is simply a different niche from C++. So while Java fixed a lot of C/C++ problems, it did so in a different context. What I'd really like to see is someone create a compiled, fast C++-like language.
Interesting post... I think you may have just intrigued me enough to give Python a try! I've sort of been mildly curious about it for years now, but I've never had the time to look into it... now I guess I'll have to make the time.
We wrote Mojo Nation entirely in Python, except for the performance-intensive parts like Crypto and low-level database, which are standard C/C++ libraries wrapped in Python interfaces.
Excellent! May I encourage you to buy the orielly book, "Learning Python"? It is a great way to get to the nitty gritty of Python's coolness. It explains some really neat Python features like tuples, lists, and dictionaries, and how Python deals with them. Though, the online documentation and tutorials are also an excellent place to start.
Re:Python stifles creativity
by
drinkypoo
·
· Score: 1
I agree, actually, and I wrote the predecessor.
If no one will moderate the post above the post I am replying to up, then someone should moderate down MY post.
-- "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Re:Python stifles creativity
by
drinkypoo
·
· Score: 1
Looseness, though, is not a virtue. Languages in which an exotic and rarely-useful construct is a mistyped character or two away from a common idiom make it way too easy for bugs to creep into code.
Looseness is a virtue. Overusing it is not. For a collaborative project, looseness is not a virtue, however, or at least taking advantage of it. You cannot blame the language for the failings of the users when the language does provide a way to do things correctly, and perl does.
...Python's indentation rule is not much beloved even among dedicated Python advocates (including myself) but we put up with it because we know it's just fluff and at least Python got the deep stuff right. By contrast, Perl's ugliness ranges all the way from the cosmetic (variable-reference syntax, quoting rules) to the deepest of the deep (bizarre scope rules, lack of an object or exception model worth the name).
And now, welcome to the same level as the person you've responded to. Don't reply with muckraking and dissing someone else's favorite language. Just tell them where they're wrong, and move on politely.
Personally, I just can't get into a language that depends so heavily on indentation, but I can see that some other people can. I'm not worrying about it. You use Python, I'll use Perl, and we'll both be happy.
-- "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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()
IANAL && First Posting
It's worth noting that this license is issued in accordance with the laws of the state of Virginia. This means that it is potentially interpreted under the UCITA which in that state comes into affect in June (or is it July?) 2001. Although Virginia seems to have toned down the provisions of the law, the terms and conditions of any EULA intterpreted in terms of the provisions of UCITA are still not acceptable to most people.
Though the license does state that it in no way is to be understood as any sort of association between the licensee and the company, the wording is vague. When it has been discussed before, it has been suggested that licensors should make crystal clear _explicitly_ that the license is not to be interpreted in terms of contract law, but is a copyright license. This is because (AKAIK) assumption that UCITA provisions are enabled in a license is the default (????)
GPL is well known to be explicitly founded on provisions of copyright law, but what about other more vaguely expressed examples? RMS has often cautioned about the risks of UCITA to all of us. I didn't take it too seriously before, but this has got me thinking.
Coming from the EU, it is possible that the European Convention on Human Rights would protect me and other citizens from most onerous attacks by licensors under UCITA (whatever Gatt 7 might say), but still I wouldn't `click through' this license until I was absolutely certain I wasn't signing up to a private contract whose terms and conditions I didn't accept.
Re:Python stifles creativity
by
drinkypoo
·
· Score: 1
If your idea of art is still life fruit bowls, Greek Revival architecture, and self-indulgent baroque like Bach, then yes, Python may be for you. Fortunately, many of us have moved on, and demand more of our art.
Then perhaps it is time for you to write a new programming or scripting language. I eagerly await your first release. Don't come back to me until it has all the functionality of perl, or python. I don't care which.
If you think some other language has the functionality, style, or what-have-you that you need, go use it, and stop slamming Python. You're just trolling, and it's working, for which I am duly ashamed. Go do something useful with your time, like getting to work ont hat coding project.
-- "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Yeah that's what I meant. The problem IMHO with Perl is that you can pass arrays (or hashes) either by value (like in Perl 4 or before), or by reference (which were introduced in Perl 5 to support nested datatypes like lists of lists... and objects, right ?).
I do think the most natural way to pass an array as a function argument is by reference (like C, Java, Pike and Ruby do), but Perl wasn't originally designed this way, therefore when references were added later on, they looked pretty strange. Whereas Ruby was designed after Perl, so could get rid of many Perl design mistakes while keeping most of its expressiveness (like its regexp notation, next if , and so on).
Re:Speed of Languages is Often Discussed
by
nd
·
· Score: 1
On second thought, I realize now that the index bounds on that second loop changes, so there isn't much way around it unfortunately.
It's not really a fair test for Python because of the way it handles for loops, but I guess you're right in that it's the 'typical' way to implement it in Python.
Maybe someone who actually has used Python more than a handful of times can give a better way (without changing the mathematical algorithm)
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.
-Billy
Re:Speed of Languages is Often Discussed
by
nd
·
· Score: 1
Sigh, on third thought, I think you should still try it with xrange() and see how that changes the results.
Re:Python stifles creativity
by
tuffy
·
· Score: 1
I stand by my original claim. You say that working with Python seemed natural to you after minimal exposure, and I don't doubt it. But
where is the challenge in that that drives you to develop truly unique solutions to new problems? Where is the exploration of the
boundries of existing algorithms?
Perl may be a mess sometimes, but many many people have reached true flashes of absolute brilliance with it that I seriously doubt
would have been possible in Python.
If your idea of art is still life fruit bowls, Greek Revival architecture, and self-indulgent baroque like Bach, then yes, Python may be for
you. Fortunately, many of us have moved on, and demand more of our art.
Languages don't make brilliant solutions any easier than my pencil makes me good at writing, and anyone who thinks otherwise has indulged in a few too many Wall'isms. A clever solution to a problem, quicksort for example, is not more or less so depending on what language it is implemented in. A language is a tool, nothing more and to think otherwise is like saying a good brush has made you a better artist.
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!
Re:Then use something different!
by
Trevor+Goodchild
·
· Score: 1
forced coding styles are kinda slack, but do enforce a standard and might make debugging or maintaining someone else's code a LOT easier!
Yes, but Python and Perl aren't really languages that should be used for long-term stuff that requires maintenance anyway. Scripting tools are best for one-off things and web development. Web scripts never last more than 6-8 months anyway. CGI has a short shelf-life, and if your company needs to figure out what the programmer that got fired last year was thinking when he did the my.yogurt-recipes.com interface, you've got serious problems. You should be doing a wholesale rewrite of everything on your site every 12 to 18 months. This is the web cycle that the online world has come to use.
Re:Then use something different!
by
mholve
·
· Score: 1
I agree with you on the Web stuff - but I was thinking more along the lines of say, system administration scripts or things along that nature. Those types of scripts don't necessarily change that much over time, but might need tweaks as new features or OS changes force you to.
As for the Website lifespan though, I must add an air of caution - while the look-n-feel of your site might change, the logic and/or code behind it might not.
Also, if you're throwing out and re-writing all of your code that often - something might be wrong. I personally write my code to be as re-usable as possible and try never to re-write anything, unless absolutely necessary!
Re:Then use something different!
by
gunga
·
· Score: 1
...Python and Perl aren't really languages that should be used for long-term stuff that requires maintenance anyway.
Well, it seems to me that zope qualifies as long-term stuff.
So how come Red Hat is moving away from Python? Remember all their tools are written in Python - things like the control panel, netcfg, printtool, etc.
Is it that they want to standardize more on C/GTK/GNOME or did Python not meet their needs?
We are not moving away from python - if anything, we're writing more and more tools in python and converting old ones.
Python is the language used in the installer and in lots of small tools...
What is probably going to go away is tcl - ugh.
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.
Hmmm, okay... For some reason it "felt" like you were moving away from the Python-based tools and moving to either curses-based or other tools - like Linuxconf, etc.
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.
Re:Whats so amazing? perl does all this
by
alleria
·
· Score: 1
More specifically, lists and scalars. This is because Perl functions depend on context.
Functions perform differently if they are in list, scalar, or void contexts.
Who cares what you think? (way OT)
by
Eladio+McCormick
·
· Score: 1
Personally, I find him [RMS] very disagreeable (all this crap about KDE developers having forfeitted their rights to certain GPL code is bogus - it completely goes against my idea of "free" software)
Frankly, whatever your idea of "free" software is, it's not fucking relevant in discussing this particular issue. It's a matter of licensing, for Christ sakes. If the KDE developers violated the GPL in the past, as RMS claims, they lost all privileges the GPL conferred them in so doing, and thus are not entitled create derivative works.
Whatever your dreamy, idiotic idea of what free software should be, this is a fucking fact about licensing, which is not affected by your trivial, ineffective intellectual machinations.
Re:Who cares what you think? (way OT)
by
rotor
·
· Score: 1
Maybe I should point out that what I'm referring to as my idea of free software is based on things that RMS himself has said. I dissagree with the guy on many things, but when he talks of what free software is, I do agree with him. Now he's going against everything he's fought for by saying that even though they've gone and corrected the things they've done wrong in the past, the KDE developers have forfeitted their rights. In using the arguments he's using, RMS is now restricting the rights he's fought to protect, and un-freeing the software, and free software is the whole point of his license.
Re:Python stifles creativity
by
gunga
·
· Score: 1
Speed isn't always the only goal. Usability and code maintenance are meaningful too. Isn't Slashdot a "real" application? If you use a GUI at all you've already traded speed for other features.
I'm unfortunate enough to spend most of my time with Visual Basic, three of my favorites:
"ADO Error: Errors occured"
"Method ~ of object ~ failed"
"Error: Catastrophic Error"
I believe the last is some kind of Windows error, which always makes me laugh. I mean, if an error is bad enough to be considered 'catastrophic', the computer better be so wrecked that it can't even tell me that. At the very least I want to turn on CNN and hear "362 people were killed in a catastrophic explosion in Uganda that is believed to be the result of a Visual Basic error originating in West Chester, Pennsylvania...". Well, OK, maybe I don't want to hear that, but at least it would justify the error message.
-- My other.sig is 'The Art of Computer Programming'
No. Python 1.5 was compatible with the GPL. The clause about the state of Virginia in the 1.6 license is the only thing that is incompatible with the GPL, and it is new in the 1.6 license.
Ugh... I hate conventional block delimitation
by
Vicegrip
·
· Score: 1
I have been the unfortunate spectator of many debates about the proper positionning of block delimitors. The only thing people always agree on is that the code needs to be indented.
I hate starting on to a project and getting used to a particular style only to have to totally adjust again because some other programmer had different ideas on where to put his brackets and align his code.... and don't get me started on naming conventions.
I for one find the elimination of traditional delimitors in Python refreshing. Its one of the things that is attracing me to the language.
-- Do not spread "09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0" over the internet, thank you.
I. Do whatever the hell you want with this code providing that you:
i. release the source to any binaries you make public
ii. give credit to the original author(s) by listing their names in a "CREDITS" file distibuted with every copy of the program.
Fine, but what about people who release the source to their software, but place restrictions on how it is used? Just because the author has given you the source code doesn't mean you can do anything with it. The GPL therefore must guarantee that NO RESTRICTIONS are placed on the use of the source. Given the complexity of contract law, this is a very difficult task.
In any case, I feel that the X/BSD style license is a much more powerful expression of freedom. Anyone can take the code and do anything they want with it. They can recombine and reuse the code in any context. If the Open Source model is so much more powerful than commercial closed source development, why does RMS fear evil capitalists so much? Their endevours are doomed, and free code wins every time. Right? So what if Apple can borrow the hard work of *BSD and give almost nothing back. What does it matter?
The FSF is a dinosaur that does far more harm than good these days. He's fighting his own now. The revolutionaries factionalize and turn on themselves...
Re:Python stifles creativity
by
Panix
·
· Score: 1
I am an artist, and code is just one outlet for my creativity. Writing, painting & sculpting are others. Since, unlike you, apparanetly, I have a fairly extensive knowledge of art, then yes, my argument makes perfect sense.
Well, that was a fairly large assumption. You seem to like making this kind of claim, that is in no way rooted in logic. I have a very respectable background in art, and I consider myself an artist of sorts as a programmer.
The mediums of expression have evolved to the point that we can not be restricted by excessive rules. Good poetry dispensed with the formality of puctuation long ago, as have all other forms of art moved beyond strict "rules" dictated by the self-proclaimed "elite" of the art world.
Strange, "good poetry" didn't part with structure and form... I wonder why that is? Generally, poetry has some form and structure to it. All the classics have a similar level of structure and form.
Perl may be a mess sometimes, but many many people have reached true flashes of absolute brilliance with it that I seriously doubt would have been possible in Python.
Well, this I find amusing. Any algorithm that you can implement in Perl can also be implemented in Python. In fact, Python is so simple and natural that I find myself attempting to express myself more, and find myself less concerned with the "finer" details of Perl.
The moderators have obviously made it clear that your claims are ludicrous, and completely void of all logic. Thank you, come again.
That's a cute haiku, but Perl vs. Python isn't really worth it. Both languages seek to occupy similar niches, but they do it with such different styles that neither is much of a threat to the other.
That's why they're idiots.
-- My other.sig is 'The Art of Computer Programming'
CNRI believes that this version is compatible with the GPL, but there is a technicality concerning the choice of law provision, which Richard Stallman believes may make it incompatible.
Does this surprise anyone? Funny, considering all the RMS talk today.
One thing that caught my eye about the Python license is that it's a clickthrough/shrinkwrap agreement--it attempts to assert bindingness based on the fact that you've downloaded it. This is in stark contrast to BSD and GPL style licenses which state what you're allowed to do, and if you don't accept the license then fine, but copyright law says you can't make a derivative work. Of course, there's not much to accept in the case of BSD, less in BSD w/o advertising, but the principle is the same: "here is when you may create derivative works and distribute", rather than "to even touch this you have to agree to a contract"
When is Python getting an optimizing compiler?
by
xonix7
·
· Score: 1
We need Python to have a compiler than compiles to machine code, not bytecode. Sure, leave the bytecode in, but add a machine-language compile option in, please!
-- Everything is but a number spoken by itself.
Re:When is Python getting an optimizing compiler?
by
xonix7
·
· Score: 1
Yeh, but can it do SWING calls?
-- Everything is but a number spoken by itself.
What's Python?
by
Anonymous Coward
·
· Score: 2
You Python/Perl weenies. I can do anything you can in awk.
Rateup ERROR: mrtg found that apache's log file time of (time) was greater than now (time)
ERROR: Let's not do the time warp, again. Logfile unchanged.
-- * And remember, it's spelled N-e-t-s-c-a-p-e, but it's pronounced "Mozilla."
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.
You know, one day I'd like to look at the web logs for that site and see just how many pages come with the referrer as/.
I mean, it's really fucking sick, but I wonder just how many people click links without checking? Of course, the parent to this post utilizes a lot of social engineering..
I agree; I prefer the BSD license. I was just letting him know the reason why they were not using the GPL. I have no idea why they didn't just use a BSD license.
I'd like to conduct an interview with the man in the picture. I have a lot of fascinating questions to ask, and I'm pretty sure that, while we want to ask the questions, the answers might frighten us.
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/
Damn good question. I have a feeling it's strictly a way of developers distancing themselves from RMS himself. Personally, I find him very disagreeable (all this crap about KDE developers having forfeitted their rights to certain GPL code is bogus - it completely goes against my idea of "free" software), and I can't blame people for not wanting to license things under something other than his license. At the same time, all these conflicts are going to kill the whole idea of free (speach) software because people aren't going to have the vast libraries of code under a conflicting license.
I now propse my own generic license:
I. Do whatever the hell you want with this code providing that you:
i. release the source to any binaries you make public
ii. give credit to the original author(s) by listing their names in a "CREDITS" file distibuted with every copy of the program.
Now, I'm waiting for the legions of flames telling me how unenforcable this is, but folks, this is freedom.
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.
Windows 95/98 or NT 4.0
a VGA graphics card capable of high (16 bit) color
If installing on Windows 95/98 you need Microsoft's Direct 3D Library (Direct X). If you do not have Direct X you can download it here.
If installing on Windows NT 4.0 you need Microsofts Service Pack 3. If you need Service Pack 3 you can download it here.
(those "download it here"'s are links to Microsoft)
-- Bid on me!
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
"...it comes in handy when you need to do some quick calculations and bc or dc seem to be too much bother."
Hmmm. With "bc" don't you just type in "1+1?";>
But I hear ya - that's what I like about Perl/{Tk,GTK} as well - the ability to rapidly work up GUIs and the logic behind it.
Unfortunately - that's what I also don't like about it... Writing GUI apps in a non-event- driven language/setting is just whack. Being interpreted also tends to make larger apps painfully slow. But then in reality, if this is what you're writing, chances are you wouldn't be doing it in Perl or Python!
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.
"I am curious how one would access the same data in a Python construct - ie, how would a python programmer retrieve *all elements of an array pointed to by a an associative array reference* ? "
That's easy. Everything in Python is really a reference to an object, so in Python terms you're talking about an entry in a dictionary (Pythonese for an associative array) that happens itself to be an array object. Ergo:
My only real problem with using Python/Perl/whatever-is-not-C is that you have to wait for bindings for all of the other libraries, lik GTK+, Gnome, libxml, etc. Half the time the only documentation available for a library has all of its examples in C alone. This may or may not be a problem, depending on how much time you want to spend doing bindings.
Staying at the bleeding edge of development is very difficult unless you are programming in the same language as the libraries you are coding against. Not that I like C, but I got tired of searching the web for bindings.
-- Opinions change daily as new information arrives. Stay tuned.
It is time for a Python topic!
by
Anonymous Coward
·
· Score: 1
I am curious how one would access the same data in a Python construct - ie, how would a python programmer retrieve *all elements of an array pointed to by a an associative array reference* ?
Python doesn't have arrays like Perl has (which contain scalars)--it has lists (which contain anything)--nor does Python use opaque references, as Perl does.
But, if you want to get at a list that's referenced by a dictionary (associative array), you'd use:
foo['bar']
-- -rozzin.
For all you people that like {braces}
by
Lord+Ender
·
· Score: 1
Some people don't like Python because it uses indentation instead of {}. Well, for all you people who miss your braces, there is a very simple way to use them in Python! Observe:
while 1: #{
...do something...
#}
There ya go! Quit whining!
-- A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Re:Speed of Languages is Often Discussed
by
Anonymous Coward
·
· Score: 1
For general Python performance issues, many of which apply to other C-based languages, see this page.
For Guido's comments on optimizing loops, see this page. One level up there are links to more good stuff, some of it outdated.
Re:Speed of Languages is Often Discussed
by
nd
·
· Score: 1
Thanks, lots of good stuff there that all Python coders should read (many things there are not immediately obvious to coders who are good at other languages, but relatively new to Python)
Does "...is really just an academic toy..." apply to Pascal as well?;>
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.
Not another language war!
by
d.valued
·
· Score: 1
If you go to China with an attitude like that, you'd better have diplomatic immunity, cuz otherwise the Communist Party loyalists will lynch you.
Pay close attention: Any language that'll do what you need it to is the best for the job. English is not as good in China as Mandarin because you can do more with it there.
Perl has a place, Python has a place, even COBOL has a place (rotting in the landiflls).
"And they said onto the Lord.. How the hell did you do THAT?!"
-- I used to be someone else. Now I'm someone better. Real life is underrated.
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.
True, you could... I'm thinking of beginning programmers - or again, coming in at a later point to code that's not documented, written poorly or whatever.
Maybe I'm a bigger fan of strong type casting than I imagine myself to be... Egads!;>
My reason for learning Python...
by
oops
·
· Score: 1
Most of my work is Java-based, but I can use JPython to script using my Java classes, which makes life very easy. Test harnesses are a doddle, and I can interrogate my class via an interactive prompt
eg. I can never remember the formatting strings for SimpleDateFormat. With JPython I just play around at the prompt until I've got what I want, and then paste the format string into my main project.
I can also write CORBA-enabled scripts, and interrogate my servers interactively.
Much as I love Perl, I don't think Python (or JPython) can be beaten for this!
Re:My reason for learning Python...
by
webcrafter
·
· Score: 1
You may like BeanShell too (www.beanshell.org)
It's scripting Java, with the semantics of Java (because it is)
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.
Peter Norvig (author of Paradigms of Artificial Intelligence
Programming and Artificial Intelligence: A Modern Approach)
wrote an interesting article comparing
Python and Lisp.
Here's an excerpt from his conclusion:
"Python is an excellent language for my intended use. It is a good
language for many of the applications that one would use Lisp as a
rapid prototyping environment for. The three main drawbacks are (1)
execution time is slow, (2) there is very little compile-time error
analysis, even less than Lisp, and (3) Python isn't called "Java",
which is a requirement in its own right for some of my audience. I
need to determine if JPython is close enough for them."
"Python can be seen as either a practical (better libraries) version of
Scheme, or as a cleaned-up (no $@&%) version of Perl. While Perl's
philosophy is TIMTOWTDI (there's more than one way to do it), Python
tries to provide a minimal subset that people will tend to use in the
same way. One of Python's controversial features, using indentation
level rather than begin/end or {/}, was driven by this philosophy:
since there are no braces, there are no style wars over where to put
the braces. Interestingly, Lisp has exactly the same philosphy on this
point: everyone uses emacs to indent their code. If you deleted the
parens on control structure special forms, Lisp and Python programs
would look quite similar."
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.
The Ruby type system works very well: it allows you to cleanly have global, local, and per-instance variables with no fuss. The names can clash easily as well and you don't have to worry about those problems because there's only one $foo, @foo is local to your object, and "foo" is local to your method invocation.
Why couldn't you just "assign"? Well, Ruby is a pure OO language, and using foo= is just another method, and member access are done using the underlying method definition obj.foo=() (which you call using obj.foo = bar). You're not "assigning" to the variable, you're calling an accessor that does something like "@foo = bar". There is no overloading of the "=" operator because it is just the assignment operator.
It's clear why Ruby's scoping is really done well and, really, optimally.
Ruby uses simple naming conventions to denote the scope of variables
Ick. IMO, such a "naming convention" is an even worse crime than Python's "indentation convention", since the former is semantic while the latter is merely syntactic. This was a dumb idea in FORTRAN, but at least they had the excuse of not having had the opportunity to learn from experience. In Perl or Ruby it's even worse than a dumb idea.
-- Slashdot - News for Herds. Stuff that Splatters.
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.
C has a wonderful transparency. You can look at a line of code and know exactly what memory is going to be touched and pretty much what the asm version is going to look like (optimizations aside). Adding OO features, or even smaller features such as boundschecking, cause that transparency to be lost.
I have been using Python for scripting, and I hope to be able to use it someday for larger applications, but on the embedded targets that I am currently developing for, Python is way too fat.
No, it's not just you. I'm continually staggered by the level of anal-retentiveness over licenses.
If I can download something, play around with it and not have to pay for it then I'm more than happy. But then, I'm easily pleased.
Re:Python stifles creativity
by
Salamander
·
· Score: 1
That's the most ridiculous false paraphrase of what I've been saying that I can imagine. I don't know why I'm even dignifying it with a response, except to ensure that my silence is not misinterpreted as acceptance.
-- Slashdot - News for Herds. Stuff that Splatters.
Re:Python stifles creativity
by
Salamander
·
· Score: 1
Its lambas are broken
I assume you mean lambdas. What do you think is broken about them, specifically?
Python DOES NOT HAVE REAL SCOPE
Ahhh, now I see your problem. The above statement is untrue. Python does have real scope. In fact, Python's scope rules are among the simplest and most understandable I've seen in a coupla dozen languages. Here's the thing, though: it's lexical scope. If you're one of those people who prefers dynamic then of course Python's scope will appear broken, and lambda expressions will be one of the most affected areas. It seems that the transition from one type of scope to the other, in either direction, takes most people a while.
Are you by any chance at MIT? I only ask because it seems like a high percentage of dynamic-scope bigots picked up their disease there. If so, you might be interested to know that you can do some kinds of continuations in Python, and there are some side projects directed at making support for your favorite programming style more complete so that old (or dumb) dogs won't have to learn new tricks.
local/global distinctions are implicit by merit of RHS vs LHS mysticism
You're not making it at all clear what you're talking about, but I'll try to guess anyway. For the onlookers, if the first reference to a variable name in a Python function is an assignment, that assignment will go into the local variable scope even if a same-named variable already exists in the enclosing module scope...unless the variable is predeclared in the function using the "global" keyword. Even worse, the idea of "first reference" is dynamic even though Python scope is generally lexical. I guess that's what the AC means by "schizo".
What's my answer to that? Well, I don't have one. I'm a Python advocate, but that doesn't mean I'm blind to its failures, and the "global" issue is one of Python's ugliest warts. Even experienced Python programmers get bitten by this occasionally. Even the relative rarity with which it occurs is no excuse, because (as I've pointed out in previous posts) it's generally good for faulty code to reveal itself as such ASAP instead of lurking until the specific conditions for failure are created.
That said, I will say that even the best programmers occasionally have bad days. Python has several warts. UNIX has some pretty bad ones too. C'est la vie. At least Python and UNIX only have warts, instead of being mostly warts on top of warts all the way to the core like Perl or Windows.
This is the kind of crap that Python shovels down your through, and which makes Perl seem direct and obvious in comparison
Anyone who can criticize Python's scoping and handling of lambda expressions, then turn around and fail to address Perl's own much greater failings in those very same areas, is the rankest sort of hypocrite.
-- Slashdot - News for Herds. Stuff that Splatters.
That's a cute haiku, but Perl vs. Python isn't really worth it. Both languages seek to occupy similar niches, but they do it with such different styles that neither is much of a threat to the other. Both are free, both have nice communities, and, despite a few quirks on either side (eg, whitespace sensitivity in Python and magic variables in Perl), both have sufficient support for solid engineering of a wide range of programs.
Perl and Python advocates should direct their spleen at scripting languages that fail to support complicated programs (eg TCL, Visual Basic, or even perl 4 style Perl), and at the misguided application of low-level languages to scripting tasks (eg writing simple applets and dynamic web pages with C and Java).
These are, IMO, causes worth promoting for the sake of better software.
PS. This comes from a Perl bigot:-)
--
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Re:Wait... don't tell me...
by
NRLax27
·
· Score: 1
Ken - right, I'm aware of the GTK bindings for Python, among other languages...
What I was wondering was if they were moving away from the purely Python-based tools to others for any specific reason, especially if it was to be a C and GNOME/GTK move...
Thanks for the clarification - makes total sense. I know there's been a lot of work on Linuxconf and others such as the Debian (?) tool.
As for "...the belief that the strengths of various languages make them better suited for some tasks and lesser suieted for others..." I couldn't agree more - I firmly believe in "use what works."
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
Re:Python stifles creativity
by
churchr
·
· Score: 1
I've seen too many huge Tcl apps that make me say that your idea of supporting "complicated programs" using it is anything but idiocy. Two irreplaceable applications, written in Tcl, that I use every day are TiK and exmh.
1) Comparison to Java: I'd have to say that Java's class libraries are generally more mature at this point. Also for server-side programming, the startup time of the JMV isn't much of an issue. It also has greater typesafety, and has a mature threading model (which is critical for many types of applications).
2) Comparison to perl: well written perl can be just as maintainable as any other language, and it's better at munging text than any of the other listed languages. Perl has a bad rap because for a long time it was deemed to be a language for quick-n-dirty scripts, so people tended to use it with a quick-n-dirty mindset. Read Damien Conway's book to see what perl can be.
3) Comparison with C++: 'really fast' OO programs are really important. C++ has gotten very complex and it's hard to write C++ compilers, so most good C++ programmers I know use about %70 percent of the features but understand them well. My experience is that well designed C++ programs ave surprisingly few memory problems. Also remember that garbage collected languages like perl and python can have memory problems if you don't think enough about how large your data structures may get; I've found this kind of memory problem to be very common.
4) Comparison with C: C doesn't have 'tragically painful' memory management. C has incredibly sinple memory mangement. Experienced C programmers know that well-thought-out designs can radically reduce the number of memory problems. I've worked on huge bodies of C code that had very few memory problems: the result of a tight, thourough design process.
C is also the most portable of the listed languages, and generally the fastest. C is the foundation that makes most computer technology possible (gross generalization alert).
I like python, and I think it has a bright future. But don't fall into the trap of seeking 'the one true language' for every occasion. Each language has strengths and weaknesses and requires a certain set of programming strategies and mindset.
Re:Python stifles creativity
by
Salamander
·
· Score: 1
Python is really just an academic toy.
Bunk. Quite a few real-world applications have been based on Python, from imaging applications to persistent object-based web scripting environments to God knows what else. Check out some of the stuff in the Vaults of Parnassus (forgot the URL, look on www.python.org) before you claim it's "just a toy".
Real world scripting requires a fast, loose, flexible approach, which is totally absent in Python.
Python is just as "fast and flexible" as any other language in the ways that matter. Looseness, though, is not a virtue. Languages in which an exotic and rarely-useful construct is a mistyped character or two away from a common idiom make it way too easy for bugs to creep into code. Languages should allow you to do tricky stuff, but the tricky stuff should be very distinct and obviously different than the straightforward stuff. Python is based on this understanding. You can do some pretty funky things with object metaprogramming and faked scopes, for example, but when you do them it's obvious to other programmers that something out of the usual is going on.
Languages have superficial features and deep features. Guess who gets all hung up on the superficial stuff? That's right...beginners. First-term Pascal programmers used to bitch and whine about "begin" and "end" all the time. As soon as they found something more important to worry about they just got over it and you should too. Python's indentation rule is not much beloved even among dedicated Python advocates (including myself) but we put up with it because we know it's just fluff and at least Python got the deep stuff right. By contrast, Perl's ugliness ranges all the way from the cosmetic (variable-reference syntax, quoting rules) to the deepest of the deep (bizarre scope rules, lack of an object or exception model worth the name).
-- Slashdot - News for Herds. Stuff that Splatters.
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!
That was a pretty nice (and convincing) reply as to the merits of Python!:)
I must admit, I'd be a little worried about it's ability to change type casts on the fly like that, and not have an identifying character as to it's type (but then C doesn't have this either) - I can certainly see it's potential for rapid development. Even Perl, as terse as it is - can be a pain in the butt sometimes, just like C can be at the other extreme at how strict it is.
It's basically all a matter of what you need your language to do! Use it for what it was designed for and you won't have any problems.
It certainly looks like Python has a lot of nice features... I'll give it a peek! Thanks.
Re:Licensing problems == UCITA
by
bockman
·
· Score: 1
Will a license change apply also to already delivered software? I see it difficult, but IANAL ( and I'm not American, too, though we started to copy all your worste laws about IP and Copyright ).
If license changes do not apply backward, there is a solution to it : fork.
-- 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
real 0m40.362s
user 0m40.138s
sys 0m0.198s
Re:Speed of Languages is Often Discussed
by
mog
·
· Score: 1
I know that this may not be the best algorithm for finding primes. That was not the point of the trials. The point was to compare identical algorithms between Python and C.
[c code for prime number finder]
#include
main()
{
int endp = 10000;
int totl = 0;
int i,j;
for ( i=2; iendp; i++ )
for ( j=2; j=i ; j++ )
{
if (j==i)
totl++;
if (i%j==0)
break;
}
printf("%d prime numbers between 1 and %d\n", totl, endp);
}
[python code for prime number finder]
#!/usr/local/bin/python
endp = 10000;
totl = 0
for i in range(2,endp):
for j in range(2,i):
if i%j == 0:
break
else:
totl = totl + 1
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?
Python is neat but....
by
buzzcutbuddha
·
· Score: 1
I have such good intentions to learn more about Python, and I have it installed on all my systems, but between my jobs desire for me to learn more DHTML and my own amazement that I can do everything I need in Perl already, I just haven't devoted the time....
Re:Python stifles creativity
by
seanb
·
· Score: 1
Why do you need it to compile? I've written several production servers in python. When the limiting factor is I/O, the scripted/compiled performance difference is largely irrelevant.
Does this ean that you don't consider Zope a "real" application? How about sketch?? Programs don't always have to be compiled to be useful.
Re:Licensing problems == UCITA
by
rjh3
·
· Score: 1
UCITA permits license changes to software already delivered.
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
Re:Python stifles creativity
by
majcher
·
· Score: 1
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.
...and this is one of the big problems I have with Python. English is nice in some ways - Proper Names are capitalized, a period ends a sentence, etc... Some programming languages take advantage of a human's ability to infer meaning from context...
I agree...
by
Anonymous Coward
·
· Score: 1
we should all use KDE instead of GNOME because that way we would all be compatible with each other ORBwise.
Basically, what you are saying is that everyone should subscribe to the license YOU like. Well, I hate the GPL, but I don't think everyone should not use it because *I* don't like it.
It is called freedom. Try it sometime.
No story about Python...
by
Happy+Monkey
·
· Score: 1
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.
I agree, actually, and I wrote the predecessor.
If no one will moderate the post above the post I am replying to up, then someone should moderate down MY post.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Looseness is a virtue. Overusing it is not. For a collaborative project, looseness is not a virtue, however, or at least taking advantage of it. You cannot blame the language for the failings of the users when the language does provide a way to do things correctly, and perl does.
And now, welcome to the same level as the person you've responded to. Don't reply with muckraking and dissing someone else's favorite language. Just tell them where they're wrong, and move on politely.
Personally, I just can't get into a language that depends so heavily on indentation, but I can see that some other people can. I'm not worrying about it. You use Python, I'll use Perl, and we'll both be happy.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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()
Python 2.0 (coming soon) has augmented assignment. See here.
IANAL && First Posting It's worth noting that this license is issued in accordance with the laws of the state of Virginia. This means that it is potentially interpreted under the UCITA which in that state comes into affect in June (or is it July?) 2001. Although Virginia seems to have toned down the provisions of the law, the terms and conditions of any EULA intterpreted in terms of the provisions of UCITA are still not acceptable to most people. Though the license does state that it in no way is to be understood as any sort of association between the licensee and the company, the wording is vague. When it has been discussed before, it has been suggested that licensors should make crystal clear _explicitly_ that the license is not to be interpreted in terms of contract law, but is a copyright license. This is because (AKAIK) assumption that UCITA provisions are enabled in a license is the default (????) GPL is well known to be explicitly founded on provisions of copyright law, but what about other more vaguely expressed examples? RMS has often cautioned about the risks of UCITA to all of us. I didn't take it too seriously before, but this has got me thinking. Coming from the EU, it is possible that the European Convention on Human Rights would protect me and other citizens from most onerous attacks by licensors under UCITA (whatever Gatt 7 might say), but still I wouldn't `click through' this license until I was absolutely certain I wasn't signing up to a private contract whose terms and conditions I didn't accept.
Then perhaps it is time for you to write a new programming or scripting language. I eagerly await your first release. Don't come back to me until it has all the functionality of perl, or python. I don't care which.
If you think some other language has the functionality, style, or what-have-you that you need, go use it, and stop slamming Python. You're just trolling, and it's working, for which I am duly ashamed. Go do something useful with your time, like getting to work ont hat coding project.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
for the Python versus Perl
idiots to post
You should upgrade to Linux 6.2 and program in Gnome.
> @{ $foo->{'bar'} }
Yeah that's what I meant. The problem IMHO with Perl is that you can pass arrays (or hashes) either by value (like in Perl 4 or before), or by reference (which were introduced in Perl 5 to support nested datatypes like lists of lists... and objects, right ?).
I do think the most natural way to pass an array as a function argument is by reference (like C, Java, Pike and Ruby do), but Perl wasn't originally designed this way, therefore when references were added later on, they looked pretty strange. Whereas Ruby was designed after Perl, so could get rid of many Perl design mistakes while keeping most of its expressiveness (like its regexp notation, next if , and so on).
On second thought, I realize now that the index bounds on that second loop changes, so there isn't much way around it unfortunately.
It's not really a fair test for Python because of the way it handles for loops, but I guess you're right in that it's the 'typical' way to implement it in Python.
Maybe someone who actually has used Python more than a handful of times can give a better way (without changing the mathematical algorithm)
Yes, it can do SWING calls. It can call arbitrary Java code. Interestingly, it also correctly handles Python's multiple inheritance.
-Billy
Sigh, on third thought, I think you should still try it with xrange() and see how that changes the results.
Languages don't make brilliant solutions any easier than my pencil makes me good at writing, and anyone who thinks otherwise has indulged in a few too many Wall'isms. A clever solution to a problem, quicksort for example, is not more or less so depending on what language it is implemented in. A language is a tool, nothing more and to think otherwise is like saying a good brush has made you a better artist.
Ita erat quando hic adveni.
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.
Is it that they want to standardize more on C/GTK/GNOME or did Python not meet their needs?
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.
Frankly, whatever your idea of "free" software is, it's not fucking relevant in discussing this particular issue. It's a matter of licensing, for Christ sakes. If the KDE developers violated the GPL in the past, as RMS claims, they lost all privileges the GPL conferred them in so doing, and thus are not entitled create derivative works.
Whatever your dreamy, idiotic idea of what free software should be, this is a fucking fact about licensing, which is not affected by your trivial, ineffective intellectual machinations.
Speed isn't always the only goal. Usability and code maintenance are meaningful too.
Isn't Slashdot a "real" application? If you use a GUI at all you've already traded speed for other features.
I'm unfortunate enough to spend most of my time with Visual Basic, three of my favorites:
"ADO Error: Errors occured"
"Method ~ of object ~ failed"
"Error: Catastrophic Error"
I believe the last is some kind of Windows error, which always makes me laugh. I mean, if an error is bad enough to be considered 'catastrophic', the computer better be so wrecked that it can't even tell me that. At the very least I want to turn on CNN and hear "362 people were killed in a catastrophic explosion in Uganda that is believed to be the result of a Visual Basic error originating in West Chester, Pennsylvania...". Well, OK, maybe I don't want to hear that, but at least it would justify the error message.
My other
No. Python 1.5 was compatible with the GPL. The clause about the state of Virginia in the 1.6 license is the only thing that is incompatible with the GPL, and it is new in the 1.6 license.
I have been the unfortunate spectator of many debates about the proper positionning of block delimitors. The only thing people always agree on is that the code needs to be indented.
I hate starting on to a project and getting used to a particular style only to have to totally adjust again because some other programmer had different ideas on where to put his brackets and align his code.... and don't get me started on naming conventions.
I for one find the elimination of traditional delimitors in Python refreshing. Its one of the things that is attracing me to the language.
Do not spread "09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0" over the internet, thank you.
i. release the source to any binaries you make public ii. give credit to the original author(s) by listing their names in a "CREDITS" file distibuted with every copy of the program.
Fine, but what about people who release the source to their software, but place restrictions on how it is used? Just because the author has given you the source code doesn't mean you can do anything with it. The GPL therefore must guarantee that NO RESTRICTIONS are placed on the use of the source. Given the complexity of contract law, this is a very difficult task.
In any case, I feel that the X/BSD style license is a much more powerful expression of freedom. Anyone can take the code and do anything they want with it. They can recombine and reuse the code in any context. If the Open Source model is so much more powerful than commercial closed source development, why does RMS fear evil capitalists so much? Their endevours are doomed, and free code wins every time. Right? So what if Apple can borrow the hard work of *BSD and give almost nothing back. What does it matter?
The FSF is a dinosaur that does far more harm than good these days. He's fighting his own now. The revolutionaries factionalize and turn on themselves...
I am an artist, and code is just one outlet for my creativity. Writing, painting & sculpting are others. Since, unlike you, apparanetly, I have a fairly extensive knowledge of art, then yes, my argument makes perfect sense.
Well, that was a fairly large assumption. You seem to like making this kind of claim, that is in no way rooted in logic. I have a very respectable background in art, and I consider myself an artist of sorts as a programmer.
The mediums of expression have evolved to the point that we can not be restricted by excessive rules. Good poetry dispensed with the formality of puctuation long ago, as have all other forms of art moved beyond strict "rules" dictated by the self-proclaimed "elite" of the art world.
Strange, "good poetry" didn't part with structure and form... I wonder why that is? Generally, poetry has some form and structure to it. All the classics have a similar level of structure and form.
Perl may be a mess sometimes, but many many people have reached true flashes of absolute brilliance with it that I seriously doubt would have been possible in Python.
Well, this I find amusing. Any algorithm that you can implement in Perl can also be implemented in Python. In fact, Python is so simple and natural that I find myself attempting to express myself more, and find myself less concerned with the "finer" details of Perl.
The moderators have obviously made it clear that your claims are ludicrous, and completely void of all logic. Thank you, come again.
That's a cute haiku, but Perl vs. Python isn't really worth it. Both languages seek to occupy similar niches, but they do it with such different styles that neither is much of a threat to the other.
That's why they're idiots.
My other
Does this surprise anyone? Funny, considering all the RMS talk today.
We need Python to have a compiler than compiles to machine code, not bytecode. Sure, leave the bytecode in, but add a machine-language compile option in, please!
Everything is but a number spoken by itself.
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.
To run Alice you must have:
Windows 95/98 or NT 4.0
a VGA graphics card capable of high (16 bit) color
If installing on Windows 95/98 you need Microsoft's Direct 3D Library (Direct X). If you do not have Direct X you can download it here.
If installing on Windows NT 4.0 you need Microsofts Service Pack 3. If you need Service Pack 3 you can download it here.
(those "download it here"'s are links to Microsoft)
--
Bid on me!
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
Hmmm. With "bc" don't you just type in "1+1?" ;>
But I hear ya - that's what I like about Perl/{Tk,GTK} as well - the ability to rapidly work up GUIs and the logic behind it.
Unfortunately - that's what I also don't like about it... Writing GUI apps in a non-event- driven language/setting is just whack. Being interpreted also tends to make larger apps painfully slow. But then in reality, if this is what you're writing, chances are you wouldn't be doing it in Perl or Python!
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.
"I am curious how one would access the same data in a Python construct - ie, how would a python programmer retrieve *all elements of an array pointed to by a an associative array reference* ? "
That's easy. Everything in Python is really a reference to an object, so in Python terms you're talking about an entry in a dictionary (Pythonese for an associative array) that happens itself to be an array object. Ergo:
foo["bar"]
And you can assign an integer to the same variable which until then contained a string.
Um, Perl does that too. Scalars can contain numbers, strings, and even pointers (except they're called referencers).
My only real problem with using Python/Perl/whatever-is-not-C is that you have to wait for bindings for all of the other libraries, lik GTK+, Gnome, libxml, etc. Half the time the only documentation available for a library has all of its examples in C alone. This may or may not be a problem, depending on how much time you want to spend doing bindings. Staying at the bleeding edge of development is very difficult unless you are programming in the same language as the libraries you are coding against. Not that I like C, but I got tired of searching the web for bindings.
Opinions change daily as new information arrives. Stay tuned.
Yes, or how about even a Python topic!
I am curious how one would access the same data in a Python construct - ie, how would a python programmer retrieve *all elements of an array pointed to by a an associative array reference* ?
Python doesn't have arrays like Perl has (which contain scalars)--it has lists (which contain anything)--nor does Python use opaque references, as Perl does.
But, if you want to get at a list that's referenced by a dictionary (associative array), you'd use:
foo['bar']
-rozzin.
Some people don't like Python because it uses indentation instead of {}. Well, for all you people who miss your braces, there is a very simple way to use them in Python! Observe:
...do something...
while 1: #{
#}
There ya go! Quit whining!
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
For Guido's comments on optimizing loops, see this page. One level up there are links to more good stuff, some of it outdated.
Thanks, lots of good stuff there that all Python coders should read (many things there are not immediately obvious to coders who are good at other languages, but relatively new to Python)
Does "...is really just an academic toy..." apply to Pascal as well? ;>
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.
If you go to China with an attitude like that, you'd better have diplomatic immunity, cuz otherwise the Communist Party loyalists will lynch you.
Pay close attention: Any language that'll do what you need it to is the best for the job. English is not as good in China as Mandarin because you can do more with it there.
Perl has a place, Python has a place, even COBOL has a place (rotting in the landiflls).
"And they said onto the Lord.. How the hell did you do THAT?!"
I used to be someone else. Now I'm someone better.
Real life is underrated.
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.
My favourite by far is:
Parse error: expect unexpected
(I actually saw this while playing with some scripts)
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
You can allways test the type of the variable, or force the value to a specific type. Dynamic typing is not as big of an issue as you might think.
"The poet presents his thoughts festively, on the carriage of rhythm; usually because they could not walk" Nietzsche
Maybe I'm a bigger fan of strong type casting than I imagine myself to be... Egads! ;>
Most of my work is Java-based, but I can use JPython to script using my Java classes, which makes life very easy. Test harnesses are a doddle, and I can interrogate my class via an interactive prompt
eg. I can never remember the formatting strings for SimpleDateFormat. With JPython I just play around at the prompt until I've got what I want, and then paste the format string into my main project.
I can also write CORBA-enabled scripts, and interrogate my servers interactively.
Much as I love Perl, I don't think Python (or JPython) can be beaten for this!
Python is not "for scripting". It's REAL programming language. It's about developing REAL applications.
Is being clean and natural a bad thing?
Use phrase 'Anatomically Improbable' more often.
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.
Peter Norvig (author of Paradigms of Artificial Intelligence Programming and Artificial Intelligence: A Modern Approach) wrote an interesting article comparing Python and Lisp.
Here's an excerpt from his conclusion:
"Python is an excellent language for my intended use. It is a good language for many of the applications that one would use Lisp as a rapid prototyping environment for. The three main drawbacks are (1) execution time is slow, (2) there is very little compile-time error analysis, even less than Lisp, and (3) Python isn't called "Java", which is a requirement in its own right for some of my audience. I need to determine if JPython is close enough for them."
"Python can be seen as either a practical (better libraries) version of Scheme, or as a cleaned-up (no $@&%) version of Perl. While Perl's philosophy is TIMTOWTDI (there's more than one way to do it), Python tries to provide a minimal subset that people will tend to use in the same way. One of Python's controversial features, using indentation level rather than begin/end or {/}, was driven by this philosophy: since there are no braces, there are no style wars over where to put the braces. Interestingly, Lisp has exactly the same philosphy on this point: everyone uses emacs to indent their code. If you deleted the parens on control structure special forms, Lisp and Python programs would look quite similar."
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.
C has a wonderful transparency. You can look at a line of code and know exactly what memory is going to be touched and pretty much what the asm version is going to look like (optimizations aside). Adding OO features, or even smaller features such as boundschecking, cause that transparency to be lost.
I have been using Python for scripting, and I hope to be able to use it someday for larger applications, but on the embedded targets that I am currently developing for, Python is way too fat.
No, it's not just you. I'm continually staggered by the level of anal-retentiveness over licenses.
If I can download something, play around with it and not have to pay for it then I'm more than happy. But then, I'm easily pleased.
That's the most ridiculous false paraphrase of what I've been saying that I can imagine. I don't know why I'm even dignifying it with a response, except to ensure that my silence is not misinterpreted as acceptance.
Slashdot - News for Herds. Stuff that Splatters.
I assume you mean lambdas. What do you think is broken about them, specifically?
Ahhh, now I see your problem. The above statement is untrue. Python does have real scope. In fact, Python's scope rules are among the simplest and most understandable I've seen in a coupla dozen languages. Here's the thing, though: it's lexical scope. If you're one of those people who prefers dynamic then of course Python's scope will appear broken, and lambda expressions will be one of the most affected areas. It seems that the transition from one type of scope to the other, in either direction, takes most people a while.
Are you by any chance at MIT? I only ask because it seems like a high percentage of dynamic-scope bigots picked up their disease there. If so, you might be interested to know that you can do some kinds of continuations in Python, and there are some side projects directed at making support for your favorite programming style more complete so that old (or dumb) dogs won't have to learn new tricks.
You're not making it at all clear what you're talking about, but I'll try to guess anyway. For the onlookers, if the first reference to a variable name in a Python function is an assignment, that assignment will go into the local variable scope even if a same-named variable already exists in the enclosing module scope...unless the variable is predeclared in the function using the "global" keyword. Even worse, the idea of "first reference" is dynamic even though Python scope is generally lexical. I guess that's what the AC means by "schizo".
What's my answer to that? Well, I don't have one. I'm a Python advocate, but that doesn't mean I'm blind to its failures, and the "global" issue is one of Python's ugliest warts. Even experienced Python programmers get bitten by this occasionally. Even the relative rarity with which it occurs is no excuse, because (as I've pointed out in previous posts) it's generally good for faulty code to reveal itself as such ASAP instead of lurking until the specific conditions for failure are created.
That said, I will say that even the best programmers occasionally have bad days. Python has several warts. UNIX has some pretty bad ones too. C'est la vie. At least Python and UNIX only have warts, instead of being mostly warts on top of warts all the way to the core like Perl or Windows.
Anyone who can criticize Python's scoping and handling of lambda expressions, then turn around and fail to address Perl's own much greater failings in those very same areas, is the rankest sort of hypocrite.
Slashdot - News for Herds. Stuff that Splatters.
Perl and Python advocates should direct their spleen at scripting languages that fail to support complicated programs (eg TCL, Visual Basic, or even perl 4 style Perl), and at the misguided application of low-level languages to scripting tasks (eg writing simple applets and dynamic web pages with C and Java).
These are, IMO, causes worth promoting for the sake of better software.
PS. This comes from a Perl bigot :-)
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Err...did you mean Cobra? ;-)
What I was wondering was if they were moving away from the purely Python-based tools to others for any specific reason, especially if it was to be a C and GNOME/GTK move...
Thanks for the clarification - makes total sense. I know there's been a lot of work on Linuxconf and others such as the Debian (?) tool.
As for "...the belief that the strengths of various languages make them better suited for some tasks and lesser suieted for others..." I couldn't agree more - I firmly believe in "use what works."
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
Why is that, again?
How long will it take
for the Python versus Perl
idiots to post
love,
br4dh4x0r
1) Comparison to Java: I'd have to say that Java's class libraries are generally more mature at this point. Also for server-side programming, the startup time of the JMV isn't much of an issue. It also has greater typesafety, and has a mature threading model (which is critical for many types of applications).
2) Comparison to perl: well written perl can be just as maintainable as any other language, and it's better at munging text than any of the other listed languages. Perl has a bad rap because for a long time it was deemed to be a language for quick-n-dirty scripts, so people tended to use it with a quick-n-dirty mindset. Read Damien Conway's book to see what perl can be.
3) Comparison with C++: 'really fast' OO programs are really important. C++ has gotten very complex and it's hard to write C++ compilers, so most good C++ programmers I know use about %70 percent of the features but understand them well. My experience is that well designed C++ programs ave surprisingly few memory problems. Also remember that garbage collected languages like perl and python can have memory problems if you don't think enough about how large your data structures may get; I've found this kind of memory problem to be very common.
4) Comparison with C: C doesn't have 'tragically painful' memory management. C has incredibly sinple memory mangement. Experienced C programmers know that well-thought-out designs can radically reduce the number of memory problems. I've worked on huge bodies of C code that had very few memory problems: the result of a tight, thourough design process.
C is also the most portable of the listed languages, and generally the fastest. C is the foundation that makes most computer technology possible (gross generalization alert).
I like python, and I think it has a bright future. But don't fall into the trap of seeking 'the one true language' for every occasion. Each language has strengths and weaknesses and requires a certain set of programming strategies and mindset.
Bunk. Quite a few real-world applications have been based on Python, from imaging applications to persistent object-based web scripting environments to God knows what else. Check out some of the stuff in the Vaults of Parnassus (forgot the URL, look on www.python.org) before you claim it's "just a toy".
Python is just as "fast and flexible" as any other language in the ways that matter. Looseness, though, is not a virtue. Languages in which an exotic and rarely-useful construct is a mistyped character or two away from a common idiom make it way too easy for bugs to creep into code. Languages should allow you to do tricky stuff, but the tricky stuff should be very distinct and obviously different than the straightforward stuff. Python is based on this understanding. You can do some pretty funky things with object metaprogramming and faked scopes, for example, but when you do them it's obvious to other programmers that something out of the usual is going on.
Languages have superficial features and deep features. Guess who gets all hung up on the superficial stuff? That's right...beginners. First-term Pascal programmers used to bitch and whine about "begin" and "end" all the time. As soon as they found something more important to worry about they just got over it and you should too. Python's indentation rule is not much beloved even among dedicated Python advocates (including myself) but we put up with it because we know it's just fluff and at least Python got the deep stuff right. By contrast, Perl's ugliness ranges all the way from the cosmetic (variable-reference syntax, quoting rules) to the deepest of the deep (bizarre scope rules, lack of an object or exception model worth the name).
Slashdot - News for Herds. Stuff that Splatters.
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
I must admit, I'd be a little worried about it's ability to change type casts on the fly like that, and not have an identifying character as to it's type (but then C doesn't have this either) - I can certainly see it's potential for rapid development. Even Perl, as terse as it is - can be a pain in the butt sometimes, just like C can be at the other extreme at how strict it is.
It's basically all a matter of what you need your language to do! Use it for what it was designed for and you won't have any problems.
It certainly looks like Python has a lot of nice features... I'll give it a peek! Thanks.
If license changes do not apply backward, there is a solution to it : fork.
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
I take it that it's not too much unlike Perl/Tk or Perl/GTK in the rapid-prototyping sense?
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?
I have such good intentions to learn more about Python, and I have it installed on all my systems, but between my jobs desire for me to learn more DHTML and my own amazement that I can do everything I need in Perl already, I just haven't devoted the time....
Why do you need it to compile? I've written several production servers in python. When the limiting factor is I/O, the scripted/compiled performance difference is largely irrelevant.
Does this ean that you don't consider Zope a "real" application? How about sketch?? Programs don't always have to be compiled to be useful.
UCITA permits license changes to software already delivered.
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.
we should all use KDE instead of GNOME because that way we would all be compatible with each other ORBwise.
Basically, what you are saying is that everyone should subscribe to the license YOU like. Well, I hate the GPL, but I don't think everyone should not use it because *I* don't like it.
It is called freedom. Try it sometime.
... is complete without a link to Alice.
___
__
Do ya feel happy-go-lucky, punk?