Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Python 1.6 Final Released 145

Posted by Hemos 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 discussion has been archived. No new comments can be posted.

Python 1.6 Final Released More

Python 1.6 Final Released

Comments Filter:

  • Great News! (Score:5)

    by Panix ( 2408 ) on Tuesday September 05, 2000 @10:04AM (#803772) Homepage

    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.

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

  • 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()
  • And I prefer Ruby to Python because Ruby has assignment syntax sugar such as +=, -=, etc.

    Python 2.0 (coming soon) has augmented assignment. See here [python.net].

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

  • My own opinion is that, other things being equal, Smalltalk is the language that needs the fewest comments to be understandable.
  • How long will it take
    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.
  • 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.

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

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

  • 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."
  • There are a LOT of languages out there - many suited to a particular application. If one doesn't suit you - use another, if possible.

    Although I certainly agree with you - forced coding styles are kinda slack, but do enforce a standard and might make debugging or maintaining someone else's code a LOT easier!

  • So why not dual license, e.g. GPL for linking with GPL'd code and artistic or BSD?

  • RedHat (Score:1)

    by mholve ( 1101 )
    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?

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

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

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

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

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

  • 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!

  • What's Python? (Score:2)

    by Anonymous Coward
    You Python/Perl weenies. I can do anything you can in awk.

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

  • GPL Compatibility issues (slightly OT). (Score:4)

    by Matt2000 ( 29624 ) on Tuesday September 05, 2000 @09:49AM (#803805) Homepage

    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.
  • How about:

    malloc: corrupt arena.

    lpr: /dev/lp is on fire.

  • What it reminds me most of is Lisp, but with indents instead of parentheses.
  • 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.

  • 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! [ebay.com]

  • Bc? (Score:1)

    by mholve ( 1101 )
    "...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!

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

  • 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!

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

  • It is time for a Python topic! (Score:1)

    by Anonymous Coward
    Yes, or how about even a Python topic!
  • 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.
  • 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']
  • 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.

    --
  • 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!

  • Re:Speed of Languages is Often Discussed (Score:1)

    by Anonymous Coward
    For general Python performance issues, many of which apply to other C-based languages, see this page [musi-cal.com].

    For Guido's comments on optimizing loops, see this page [python.org]. One level up [python.org] 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)

  • Re:GPL Compatibility issues (slightly OT). (Score:3)

    by jhylton ( 65650 ) on Tuesday September 05, 2000 @10:19AM (#803824) Homepage

    The Python 1.6 License FAQ [python.org] 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...

    You can find even more information in the license-py20 mailing list archive. [beopen.com] The most recent post from Bob Weiner, BeOpen's CTO, says:

    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..
  • Does "...is really just an academic toy..." apply to Pascal as well? ;>
  • 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.

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

  • Heaven forbid anyone should do anything interesting on Windows.
  • 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?!"
  • 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?
  • My favourite by far is:
    Parse error: expect unexpected
    (I actually saw this while playing with some scripts)
  • One can get "develop an OO application really really fast" and "get a really really fast OO application" *AT THE SAME TIME*!

    Code the app in Python. You'll get the fast development.

    Profile the app. Rewrite the slow bits in C. You'll get the fast app.

    In the end, you get 90% of the speed with 1/3rd the effort. Not a bad deal a'tall.


    --
  • Python r2.0 is on its way, coming soon to a [BeOpen] [pythonlabs.com] site near you.

    Among its other features, as listed in a [What's New] [python.net] 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] [python.net].


    --
  • 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!

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

  • Re:Speed of Languages is Often Discussed (Score:4)

    by kjz ( 26521 ) on Tuesday September 05, 2000 @12:23PM (#803837)
    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
  • 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.
  • Did you notice that the guy is wearing a wedding band? Food for thought
  • 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.
  • 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.

  • Vars (Score:1)

    by mholve ( 1101 )
    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! ;>

  • ...is JPython [jpython.org]

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

  • Touche.

    However, despite the fact that Alice [alice.org] is decidedly not aimed at the geek crowd, the fact remains that it is pretty darn cool.

    And linking to MS is fairly reasonable to get "Service Packs" and DirectX updates.
    ___

  • 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. :)

  • Re:RedHat (Score:3)

    by KenCrandall ( 13860 ) on Tuesday September 05, 2000 @10:31AM (#803850) Homepage
    As a former Red Hatter, let me offer some clarification on this.

    First of all, just becuase something is GNOME-aware (or even uses GTK+ as its widget set) does not exclude Python as its programming language. There's PyGNOME and PyGTK which provide excellent bindings to GNOME and GTK, respectively, for those who wish to write GNOME- and GTK-aware programs in Python. (The Red Hat installer, Anaconda, which uses GTK is written in Python, for example.)

    The Red Hat utilities, I believe, that you are referring to (netcfg, printtool, control-panel, timetool, etc.) are old and were, at the time, "quick-hacks" to enable GUI configuration of common services to newer users. Last I heard, Red Hat planned to work on/contribute to newer tool that fit into the GNOME framework to perform those same actions. I have no idea whether or not they would be coded in Python.

    As far as what Red Hat believes to be the roles of various languages to be is their call, but while I was there, there was the belief that the strengths of various languages make them better suited for some tasks and lesser suieted for others.

    Ken
  • 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 [norvig.com] 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."

  • Really?

    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.

  • What about Ruby ? (Score:3)

    by Jérôme Zago ( 17794 ) <slashdot-user@NOsPAM.agt-the-walker.net> on Tuesday September 05, 2000 @11:01AM (#803854)
    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.

    Anyway, for a better overview of Ruby, look at: The Ruby Home Page [ruby-lang.org]

  • ...you can combine Python and Java by using JPython [jpython.org]

    See my related post on this! [slashdot.org]

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

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

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

  • Haiku (Score:4)

    by br4dh4x0r ( 137273 ) on Tuesday September 05, 2000 @09:50AM (#803877)
    How long will it take
    for the Python versus Perl
    idiots to post

    love,
    br4dh4x0r
  • 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
    --

  • Re:Python (Score:3)

    by bockman ( 104837 ) on Tuesday September 05, 2000 @10:40AM (#803887)
    I take it that it's not too much unlike Perl/Tk or Perl/GTK in the rapid-prototyping sense?

    IMO, python is better for rapid prototyping, because of is more dynamic than Perl, it gives more freedom to the programmers and and has a less encumbered syntax.

    For instance, you do not need to qualify variables in any way ( not event with the pre-pended special characters Perl uses). And you can assign an integer to the same variable which until then contained a string. This is a bonus for fast prototyping , altough it might lead to troubles in in the hands of bad programmers ( but the same might be said of many features of more constrained languages ).

    Python is also better in doing Object Oriented stuff - in this is even better than C++ ( not that it takes much ), and as good as Java.

    The drawback is that you pay all this in performance. But for several classes of application, this is not an issue.

    And Python is incredibly easy to learn. Give it a try!

    Sorry for the sermon, but I quite like Python.

  • 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.
  • Happened Already
    What a gigantic surprise
    Idiots march on.
  • 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

  • Ah. That could well be. There's certainly some suspicions about CNRI and its bid to trademark the name Python.

    CNRI may be innocuous. Or they may be set to really shit all over the Python world. It's impossible to tell from way over here.

    [sigh]


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

  • In that case, the LGPL should be used instead of the GPL. That is, after all, what the LGPL was written for.

    Bill - aka taniwha
    --

  • 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 [dictionary.com] strikes again:
    application [dictionary.com] 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 [dictionary.com], application s programme [dictionary.com]]. 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 [dictionary.com] 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 [dictionary.com] to clear things up. It will save you the embarrassment and me the trouble of the tedium of your correction.

  • Python 2.0b1 also due out today (Score:5)

    by Corvus ( 27991 ) on Tuesday September 05, 2000 @11:35AM (#803910) Homepage
    According to Guido here [python.org].

    That is all.

  • Re:What's Python? (Score:2)

    by Anonymous Coward
    Yep! But awk is so ... awkward.

Slashdot Top Deals

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Close