Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming IT Technology

Python 2.4 Final Released 359

Eventh writes "The final release of Python 2.4 was just released. Python 2.4 is the result of almost 18 month's worth of work on top of Python 2.3. New features are, but not limited to, function decorators, generator expressions, a number of new module and more. Check out Andrew Kuchling's What's New In Python for a detailed view of some of the new features of Python 2.4. "
This discussion has been archived. No new comments can be posted.

Python 2.4 Final Released

Comments Filter:
  • genexps (Score:5, Insightful)

    by ultrabot ( 200914 ) on Tuesday November 30, 2004 @12:45PM (#10953569)
    You forgot the most important improvement, the "generator expressions".

    From the AMK's excellent (as always) overview:

    print sum(obj.count for obj in list_all_objects())

    The important part is that no intermediate list is generated, because we are dealing with generators.

    Generators in general kick so much ass it's not even funny.
  • Python annoyances (Score:2, Insightful)

    by Anonymous Coward on Tuesday November 30, 2004 @12:50PM (#10953625)
    Python is a pretty good language for general use and for teaching. If fact, what got me interested in Python was a story (on Slashdot) about programmers at Sun saying that Python was a better language than Java in their environment.

    Having said the above, there always seem to be 'issues'. Floating point numbers are one such issue. This release fixes that with 'Decimal'. The trouble is, you have to know about 'Decimal' before you can use it. This raises the difficulty of using Python.

    I find that I write code quickly and then spend an hour researching some module or other. It sure slows down the process.
  • by donniejones18 ( 749882 ) on Tuesday November 30, 2004 @12:52PM (#10953639) Homepage
    What were Linus' comments?
  • Re:OK Trolls... (Score:2, Insightful)

    by rhaig ( 24891 ) <rhaig@acm.org> on Tuesday November 30, 2004 @12:58PM (#10953701) Homepage
    whitespace, when used correctly, makes code readable. However, having the inability to be flexible with the use of that whitespace bugs me.

    coding standards make good code, not a language. I can write bad python just as easially as I can write good perl.
  • by Anonymous Coward on Tuesday November 30, 2004 @01:09PM (#10953815)
    Why don't you try Ruby? It's like if Python was designed properly to begin with.

    Here's your example in Ruby for instance:
    puts Dir['/tmp/*']
  • by oexeo ( 816786 ) on Tuesday November 30, 2004 @01:09PM (#10953821)
    BTW, why would you want to get more proficient in C? Programmers are abandoning C in droves. It's just not programmer-time efficient to do things in C anymore. It's one thing if you are maintaining a project that was written in C originally, but for new projects, C is a non-starter.

    I think one of the problems is too many people are still spreading the myth that it's essential to learn C before moving on to C++, which is totally false, C++ is a language in itself, and can be treated as such. Learning C (unless you intend to use it) is a waste of time, and I would go so far to say learning C first will make you less producive in C++, because it teaches concepts which are not applicable, or are actually bad habits when used in C++. At least that's my view on the subject.

    That said, C still has its uses, but for many projects (like parent said) it's a "non-starter"

  • by Anonymous Coward on Tuesday November 30, 2004 @01:11PM (#10953833)
    Here's a novel idea: Use the right tool for the job. There's a very large class of problems for which neither c nor bash are particularly appropriate programming languages. I suspect that Linus was attempting to comment on the partcular classes of problems on which he typically works, not on the merits of any specific programming language. If everything you're doing now can be done with bash, then use bash. However, don't rule out Python just because Linus doesn't use it. One day, you'll need to do something that's impractical with bash, and you'll find Python quite useful.

    I use Python extensively in my day-to-day work. It's the most versatile tool in my toolbox, and I'm continually amazed that so few people, at least around here, use it.
  • by Onimaru ( 773331 ) on Tuesday November 30, 2004 @01:16PM (#10953881)

    I've always liked Python, but I don't think this update is enough to make me learn it.

    In one respect, it is exactly what I've been hoping for. No more sweeping changes or vast syntactic variances, but they have eliminated some usability problems and silly errors. It's a very mature language now, and seems to be behaving as such, this makes me happy

    Still, though, they seem to be competing for a niche that Perl has a deathgrip on for me. I use Bash whenever I can, Perl when I can't or it would be ugly, and C when I feel like I haven't had my eyeballs gouged out with hot pokers enough lately -- er, I mean when performance is at a premium.

    Python's capabilities seem to rapidly be approaching what I can do with C, and God knows I want to never malloc() again, but as long as compiled binaries can be made only "Not easily," I don't think it's going to unseat Perl for my heavy-duty scripting language slot.

  • Re:18 Months (Score:5, Insightful)

    by MikeBabcock ( 65886 ) <mtb-slashdot@mikebabcock.ca> on Tuesday November 30, 2004 @01:20PM (#10953939) Homepage Journal
    Its not that they're hard to parse, its that they're unnecessary and ugly.
    if (x == y)
    {
    if (!do(something))
    {
    printf(failuremsg);
    return -1;
    }
    return 0;
    }
    vs.
    if x == y:
    if not do(something):
    print failuremsg
    return -1
    return 0
    Linus' comments in the kernel's CodingStyle document are relevant too -- try to keep your functions so that you can read most of them on one screen. Python allows you to do this more often (I find) without resorting to strange brace positions.
  • Re:Supprised (Score:5, Insightful)

    by kirkjobsluder ( 520465 ) <kirk@@@jobsluder...net> on Tuesday November 30, 2004 @01:21PM (#10953950) Homepage
    Can one tell me why I should learn python and not any other programming language anyway?

    Well, some of the things I like about python:
    1: tightly structured code.
    2: less punctuation.
    3: more readable syntax.
    4: full OOP from the ground up (in contrast to perl where the OOP is bolted on with references).
    5: short production cycle.

    Many of these things can be found in other languages as well. So it largely comes down a matter of preference.

    From the little I have seen, python seems to be a command line language. Is it anywhere similar to Visual Basic, which I have come to see and experience through a GUI?

    Check out tkinter and wxPython.
  • Re:Is it just me? (Score:5, Insightful)

    by pclminion ( 145572 ) on Tuesday November 30, 2004 @01:27PM (#10954014)
    If a newbie writes something that can be re-written with a list comprehension for instance, it's pretty much given that nobody will actually answer his question, choosing instead to re-write his program for him using tricks and shortcuts.

    List comprehensions are not "tricks," they are an extremely powerful language feature. Newbies should be taught how to use them, and translating their loop-based code into list comprehensions is probably the best way to do that.

    Python can be written from either an imperative standpoint or a pseudo-functional one. Most of the highly skilled Python programmers code in the pseudo-functional style, because it is more efficient and (arguably) more elegant.

    Sure, you can get into some pretty scary territory with various combinations of sum(), map(), reduce(), and list comprehensions but that's your choice. I admit that there should not be such a big performance gap between the different styles... This is due to not enough effort being spent on improving the VM.

  • by geg81 ( 816215 ) on Tuesday November 30, 2004 @01:31PM (#10954058)
    I'm not sure what it means, but Python is looking an awful lot like CommonLisp, down to the somewhat controversial syntax.

    There are two big differences. One is that CommonLisp made it a lot easier to treat programs as data and vice versa, and it had a built-in high-performance native compiler. On the other hand, Python integrates a lot better with Linux and UNIX, there are tons more libraries for it, and is easier for new users to learn.
  • by ceeam ( 39911 ) on Tuesday November 30, 2004 @01:34PM (#10954085)
    (Warning: Flamebait lookalike ahead).

    IMHO - there are still uses for C, there are absolutely no uses for C++ nowadays. Moreover - there is no C++. I mean - I've been tracking (and sometimes using) C++ developments since the early days till recent and I can tell you - the amount of pileup that they produced in modern C++ compared even to early C++'s (not to say about more sane languages) is totally ridiculous. No - inventing a new language construct for bloody every particular problem does not make a good language. Well - if you want a complex system - use dynamic languages (Python, Lisp, Smalltalk - whatever suits you. Heck - PHP even if you know how to manage your globals). If you want something small and embedded - you should not overcomplicate - use C (refer to Linux sources, for example, to see how people code in C). If you want low-level performance and reliability in complex systems - I hate to say it, but use Java (large portions of IL2 - flight simulator - are written in Java, totally amazing stuff). Of course, if you like brainfucking - C++ may be for you, but it's really a bird that does not fly. On amount of time and energy that you'll waste on learning C++ you can pick half a dozen of better languages.

    If still not convinced - check out how many CPU instructions are wasted for such a simple thing as returning a C++ string object from a function. When I show it to C++ "gurus" many are enlightened. :)
  • Re:Damn (Score:2, Insightful)

    by slinkp ( 136716 ) on Tuesday November 30, 2004 @01:35PM (#10954096) Homepage
    Don't worry about it. It's still a good book and very little (if anything) has changed that affects the book's accuracy. It won't tell you about new features of course, but those are all either dead easy to learn or not likely to matter to the average new pythonista.
  • by Anonymous Coward on Tuesday November 30, 2004 @01:38PM (#10954125)
    Python looks NOTHING like common lisp.

    For once thing is the "big difference" you describe: you can't transparently process code as data. That means no MACROS, which is what makes Lisp so damn powerful.

    I think people see "lambda" and they somehow think that Python has something to do with Lisp.

    How do you return an anonymous function from a function in Python? How do you build a function at run time? It's not easy or obvious.
  • by dstone ( 191334 ) on Tuesday November 30, 2004 @01:42PM (#10954164) Homepage
    Currently in Python, the C floating point libraries used will produce this:

    >>> 1.1
    1.1000000000000001

    Thus, the Decimal data type was born.

    From PEP 327: "The inaccuracy isn't always visible when you print the number because the FP-to-decimal-string conversion is provided by the C library, and most C libraries try to produce sensible output. Even if it's not displayed, however, the inaccuracy is still there and subsequent operations can magnify the error."
  • sigils sneaking in (Score:4, Insightful)

    by CatGrep ( 707480 ) on Tuesday November 30, 2004 @01:50PM (#10954242)
    So now that Python is using the '@' character for function decorators the Pythonistas can no longer crticize other languages like Ruby (which uses sigils responsibly) for their use of '@' (I'm not including Perl in the list of languages that use sigils responsibly, btw :)

    Welcome to the sigil club! Pandoras box is now open! '$' can't be too far behind :)
  • by Zaak ( 46001 ) on Tuesday November 30, 2004 @01:55PM (#10954293) Homepage
    If all the C programmers vanish, what are we going to write the next generation of high-level languages in?

    That's a very good question. However, just because programming in C is difficult doesn't mean that it's the best language to write high-level languages in. C has many design flaws that people have gotten so used to, they assume there's no other way of doing things.

    If you like programming in C because it's a challenge, then by all means do so. However, I would classify that hobby with people who program in Intercal and similar. Those languages are challenging too.

    I see a real need for a language that is as easy to program in as Python, yet as potentially fast as C. As far as I know such a language doesn't exist yet, but I see no fundamental obstacles preventing us from creating one. It's just a matter of time.

    Do you really want a future where not a single person actually knows what is happening inside that CPU, just because "it's hard?"

    Yes, an essential part of a programmer's training is learning exactly what is happening inside the machine. However, a human being cannot keep track of everything at once. That's why we use abstraction. A high-level language (not C) abstracts away the details the computer is smart enough to handle, and leaves the material which the computer is not smart enough to handle.

    Programming is fundamentally hard. Making the job harder than it needs to be can be fun, but for day-to-day work, it just doesn't make sense.

    TTFN
  • Re:OK Trolls... (Score:2, Insightful)

    by garaged ( 579941 ) on Tuesday November 30, 2004 @02:13PM (#10954479) Homepage
    I can see you code on windows :-) Use Vim for the sake of god !
  • Re:Supprised (Score:3, Insightful)

    by pHDNgell ( 410691 ) on Tuesday November 30, 2004 @02:58PM (#10954981)
    Can one tell me why I should learn python and not any other programming language anyway? ...uh, because your brain is actually capable of learning more than one way to do things. Some people even know up to *three* programming languages!

    Sarcasm aside, it's not uncommon for me to work in four vastly different programming languages in a single day (usually java, ocaml, python, and C). That's not counting the ``lesser'' languages like sh, javascript, etc...

    If I hear people talking about how a language or development environment does wonders for their productivity, I'll give it a shot. I can usually pick up languages pretty fast. I admit it took me a week or maybe even longer before I really ``got'' ocaml, though. But I had a good time trying. :)

    I learned python initially because it had the best xmlrpc implementation. My first actual project was one that read a format definition for the tiger database and then used it to parse all of the zip file exports to load them into postgres. I ran it on several machines for about a week with very few errors (my own errors, that is) after spending a couple of hours writing the loader. That impressed me quite a bit for my first use of a language.

    Don't look for an excuse to learn something, though. Just do it. Give it some time. If you don't like where it's taking you, then take what you got out of it and learn something else.

    If all you know is VB, though, it's going to take quite a bit of learning before you know what a good language feels like.
  • WTF? (Score:4, Insightful)

    by ArbitraryConstant ( 763964 ) on Tuesday November 30, 2004 @02:59PM (#10954982) Homepage
    Linus is not some kind of deity. He (by his own account) does nothing between kernelspace and small scripts.

    I'm very proficient with C, Python and Bash, and I can tell you for a fact: Bash and Python barely compete against each other.

    Bash has nothing in the way of nice datatypes. Bash is very slow while Python can be nearly as fast as C (I've gotten it up to 80% when relying heavily on C libraries like regex). Bash can't do more than the most trivial things without helper programs, which while useful, takes forever because it has to keep spawning processes.

    For a high level language, Bash has pathetic memory management. Pretty much the only way to get some things done is tempfiles, which is worse than malloc because they're not removed if you don't clean them up.

    If you can't hold more than two languages in your head, go home and learn Java and C#. You're only going to get made fun of on slashdot.
  • by Anonymous Coward on Tuesday November 30, 2004 @03:01PM (#10955010)
    But seriously, Common Lisp is the Common Lisp for the 21st century. It's doing quite nicely

    Well, it's not dying, but it's not exactly flowering either.

    Common Lisp still needs what it has needed for nearly two decades: a cleaned up and thoroughly revised standard. There is a lot of cruft in it that simply doesn't matter anymore these days.
  • by curne ( 133623 ) <curne@nOspAM.curnomatic.dk> on Tuesday November 30, 2004 @03:02PM (#10955029) Homepage
    ...I am inclined to get more profficient with Bash and C...

    But Bash does not do anything. To accomplish something you have to use all the command line tools, like grep, sed, and awk. Put those tools in the language and you have Ruby or Perl.

    Shell scripts are only really quick to develop because they mirror what we would type via the CLI. Thus the name, "script".
  • by pkhuong ( 686673 ) on Tuesday November 30, 2004 @03:08PM (#10955091) Homepage
    No. This shows that interval arithemtic is needed. Why can't I know the precision of results? The printer should be able to know that the value is only accurate to n decimals (or binimals or whatever they're called :), and not print more. We let programs make a mistake that would have made us lose marks in Junior High, and (hopefully? I'm in health now, so I don't know) failed us in College.
  • python - awesome (Score:5, Insightful)

    by hashmap ( 613482 ) on Tuesday November 30, 2004 @03:08PM (#10955094)
    In some of my last projects I had to analyze a Perl and a Java program. I programmed a few years in both of these, but now after a year with Python I was truly suprised of how primitive these languages felt.

    All those funny symbols, casting back and forth in perl just getting in the way yet don't really say anything useful ... here is an example:

    foreach my $val(@{$G->{spec_val}}) {
    ...@{$G->{species}} = $G->{dbh}->selectrow_array($G->{sth_species},undef ,$val);
    ...if(@{$G->{species}}) {
    ......$G->{spec_label}{$val} = $G->{species}[0]. '; '. $val;
    ...}
    }

    whether or not this is good code is not the point, I have to make it work, look at all that pointless markup, in python this same thing would look like this:

    for val in G.spec_val:
    ...G.species = G.dbh.selectrow_array(G.sth_species, None, val)
    ...if G.species:
    ......G.spec_label[val] = G.species[0] + ';' + val

    (leading . stands for a space )which version would you rather read?

    or that uselessly verbose java where you have to write X number of lines before any action starts ...

    Python is a simple, clean and powerful language where the real value comes tomorrow or next month, when you have to understand and modify what you wrote today. There are no objective measures of this quality you have to try it to believe it.

  • Re:genexps (Score:5, Insightful)

    by CoughDropAddict ( 40792 ) on Tuesday November 30, 2004 @03:23PM (#10955276) Homepage
    At a language level, it's true that generators don't have anything to do with lambda or code blocks. But when you consider what these features are used for, there is some overlap.

    Consider the example you gave:
    print sum(obj.count for obj in list_all_objects())
    In Ruby, you can accomplish the same thing by writing:
    print (objGenerator.map { |obj| obj.count } ).sum
    where "objGenerator" is an object that mixes in the "Enumerable" module. An even better way (that really avoids building an intermediate list, even of integers) is:
    a = 0
    objGenerator.each { |obj| a += obj.count }
    print a
    There is one thing that generators give you that blocks can't, that is very, very cool. With a generator, you can create programs with a pipeline architecture, where different steps of the pipeline all can be written as if they have the main loop.

    Imagine you are writing a compiler. You could write (be easy on my syntax, I haven't written Python in a while)
    def lexer(input):
    state = STATE_BEGIN
    ch = input.read(1)
    if state == STATE_BEGIN:
    if ch == '(':
    yield TOKEN_LEFT_PAREN
    (...)

    def parser(lexer)
    token = lexer.get()
    if token == TOKEN_LEFT_PAREN:
    yield parse_expr(lexer)
    # gobble TOKEN_LEFT_PAREN
    lexer.get()
    (...)
    The beauty is that both your lexer and your parser can be written as if they have the main loop, and all they have to do is yield a token/expression when they find one. In reality, it's pipelined and you get the efficiency of not having to build up the entire list of tokens before you start parsing.
  • Re:Is it just me? (Score:4, Insightful)

    by tungwaiyip ( 608795 ) on Tuesday November 30, 2004 @03:27PM (#10955343) Homepage
    The 'one best way to do it' mostly mean basic language operations, like iterating over a list. Many recipes in the Python cookbook are really mildly complex utility programs. They are differ in features, complexity, performance and intented use. The are naturally many ways to do similar things. And if you take these variables into account, you will find they are not really doing the 'same' thing.

    Since Python 2.x there is a move toward iterators and generators. Rather than seeing this as bloats I would say this Python is maturing to handle real world applications. If you are handling simple data and performance is not an issue, use regular lists. If you writing application to handle arbitrary large data set or performance is an issue, go for iterators and generators. List comprehension is a neat language construct but I don't see any need to rush rewriting anything.
  • Re:genexps (Score:4, Insightful)

    by CoughDropAddict ( 40792 ) on Tuesday November 30, 2004 @03:34PM (#10955439) Homepage
    Oops, I realized that probably the best way to do this in ruby is to use inject:
    print objGenerator.inject(0) { |sum, value| sum + value }
    No intermediate list, and you don't have to rely on having a function like "sum" defined -- it could be any operation.

    You could also add this to the "Enumerable" mixin:
    module Enumerable
    def sum
    return inject(0) { |sum, value| sum + value }
    end
    end
    Now you can call "sum" on any object that implements "Enumerable", and the example becomes:
    print objGenerator.sum

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Working...