Slashdot Mirror

← Back to Stories (view on slashdot.org)

Python 2.2.1 Released

Posted by michael on from the squeeze-play dept.

An Anonymous Coward writes "It appears that the latest version of Python has been released. "We are pleased to announce the release of Python 2.2.1, on April 10, 2002. This is a bug-fix release for Python 2.2 and supersedes the 2.2 release." As far as what's new, it says,"This being a bug-fix release, there have been no exciting new features implemented since 2.2 -- just heaps of fixes.""

19 comments

  1. Yay for the Snake by IpalindromeI · · Score: 1, Redundant

    Hurray for Python. It's come a long way, and the Python community is great. To find out what's new, see the release notes.

    --

    --
    Promoting critical thinking since 1994.
  2. We are pleased to annouce by Anonymous Coward · · Score: 0
    "We are pleased to announce the release of Python 2.2.1, on April 10, 2002. This is a bug-fix release for Python 2.2 and supersedes the 2.2 release."
    We are pleased to announce that our last release was buggy crap.
  3. icons, /.?? by Anonymous Coward · · Score: 2, Interesting

    perl and java have their own topic icons, why not give a snake or something to Python??

    1. Re:icons, /.?? by Rick+the+Red · · Score: 2

      Perhaps Python Puzzles People?

      --
      If all this should have a reason, we would be the last to know.
  4. I wonder....... by (startx) · · Score: 1

    If he can squeeze the work bugfix in there one more time? oh well, at least ppl know it's safe to upgrade.

  5. Why python? by Snowfox · · Score: 3, Interesting
    I know zero about python. I use C and C++ almost exclusively.

    From a high level view, what makes python great? Where is python one of the best tools for the job? What are its strengths, and where is it most often used?

    1. Re:Why python? by rjh · · Score: 5, Informative
      1. Clean human-readable syntax.

        The syntax is clean and easy for us mere humans to read. For instance, compare the two following bits of code (one in C++, the other in Python):

        #include <iostream>

        using std::cout;
        using std::endl;

        int main(int argc, char *argv[])
        {
        unsigned long int fact = 1, x = 1;
        for (x = 1 ; x < 6 ; x++) fact *= x;
        cout << x-- << " factorial = " << fact <&lt endl;
        return fact;
        }
        ... So far it's pretty obvious to C++ programmers what you're doing, but to anyone who doesn't know C++, even an example this simple borders on meaningless gibberish. What does "#include" mean? What do those `::'s mean in the using statement? What's cout and why do I care? What's char *argv[], and why do some people write it as char **argv?

        The Python version of this same program, though, is beautifully simple to read:

        def factorial(num):
        fact = 1
        for x in range(1, num + 1):
        fact = fact * x
        print fact
        return fact

        if __name__=='__main__':
        factorial(5)
        The Python code, while similar in lines of code, is enormously clearer. If you're willing to write functional Python code, it's even better:

        def factorial(num, passfwd):
        if num == 0: print passfwd
        else: factorial(num - 1, passfwd * num)

        if __name__=='__main__':
        factorial(5, 1)
      2. Multiparadigmatic.

        As a C++ coder, you're familiar with C++'s Every Paradigm And The Kitchen Sink approach. C++ lets you use generic programming, procedural programming, OO programming--whatever you need to get the job done. Python is the exact same. The OO syntax is clean, terse and readable; operator overloading is straightforward; and as my above example shows, functional programming is easy within Python.

        Unlike some other interpreted languages (coughcoughJavacough) which coerce you into solving every problem via their One True Way (OO, usually), Python lets you solve problems the way you want to solve them.
      3. Crossplatform.

        Python might not run everywhere, but it runs everywhere I'm interested in being. It's possible to write crossplatform code with C/C++ (especially if you write code intelligently), but there are enough hardware gotchas to make crossplatform code difficult.
      4. Fun.

        Python is just plain fun. :)
      5. Extensible and Embeddable.

        Python can easily be extended via C/C++ code, and it can easily be embedded within C/C++ code as a scripting language. This can often make for extremely impressive rapid application development; write the app in Python, then profile it and widen out the bottlenecks by writing them in native code. Doing this, I've managed to get performance approaching that of native code without anywhere near the headaches of writing the entire thing in native code.
      6. Lots of libraries.

        Much like Perl, the available libraries for Python are mind-boggling. Check 'em out. :)
      7. Easy GUI programming.

        PyQt, PyKDE, PyGTK, PyGNOME, and a Win32 Python modules are all actively maintained. There are even Python GUI libraries for BeOS.

      ... I use C++ a fair bit, and I love the language. C++ is probably my favorite "mainstream" language, even if it does have a learning curve like the Matterhorn. But even though I love C++, I love Python just as much.

      Python is not a replacement for C/C++. It wasn't meant to be, either. But as an adjunct to C/C++, Python is magnificent. :)
    2. Re:Why python? by GoodmansonD · · Score: 2, Informative
      I can't answer all of your question as elequontly as the previous post, but add a few handy links.

      I've have found it an excellent relief from the mundane of C/C++ while re-inforcing the natural idioms of generic programming. I'm Looking forward to working with the Boost Python Library

      A survey contrast of Python and C++ http://mail.python.org/pipermail/python-list/2002- April/096602.html Cross platform, Batteries included, good natured community, and script -> OO Ready got me interested, "like I think" factors got me hooked. (I'm a C++/C applications developer.) The Weekly Guide to Python Resources

    3. Re:Why python? by hoggy · · Score: 3, Informative

      The Python code, while similar in lines of code, is enormously clearer. If you're willing to write functional Python code, it's even better:

      Erk. The correct functional formulation of this problem is:

      >>> def fact( n ):
      ... if n == 0:
      ... return 1
      ... else:
      ... return n * fact( n - 1 )
      ...
      >>> fact( 5 )
      120

      Or, more succinctly (and more stack efficient):

      >>> import operator
      >>> def fact( n ):
      ... return reduce( operator.mul, range(1, n+1) )
      ...
      >>> fact(5)
      120

      The above samples cut-n-pasted from a Python interactive session also show more clearly how a new user would learn the language. Like the Good Old Days of computers that booted straight to BASIC interpreters, Python allows you to experiment with programming by just typing fragments of code at the prompt and trying them out.

    4. Re:Why python? by brunns · · Score: 1

      Here's why.

      --

      If you moderate me down I shall become more powerful than you can possibly imagine.
    5. Re:Why python? by rjh · · Score: 2

      The correct functional formulation of this problem is

      Please find me where the code I posted is either incorrect (i.e., fails to give a correct result) or less than functional. :) I wrote it the way I wrote it because it's a terse, tail-recursive two-liner--admittedly, the tail recursion isn't the conventional Python style, but the fact that it's tail recursive is immediately evident. The code was meant to demonstrate the ease with which you can do functional programming in Python, not as a "you should do functional programming just like this".

      The reduce version is considerably slower than either of the two recursive versions, by the by, probably due to the time it takes for import to execute.

      The recursive version, for n = 998:
      real 0m0.079s
      user 0m0.060s
      sys 0m0.020s

      The reduce version, for n = 998:
      real 0m0.108s
      user 0m0.060s
      sys 0m0.020s

    6. Re:Why python? by hoggy · · Score: 2

      Please find me where the code I posted is either incorrect (i.e., fails to give a correct result) or less than functional. :)

      I knew I'd get pulled-up for using the word "correct" ;-) I meant to say that this is the standard functional formulation of the problem. You're point was that Python is readable, but the examples you gave are idiomatic and not the most readable versions.

      I wrote it the way I wrote it because it's a terse, tail-recursive two-liner--admittedly, the tail recursion isn't the conventional Python style, but the fact that it's tail recursive is immediately evident.

      Python doesn't optimise the tail recursion away, so the version you gave still eats stack. Given that you're not winning anything by being tail-recursive, you might as well go for the more standard mathematical form.

      The reduce version is considerably slower than either of the two recursive versions, by the by, probably due to the time it takes for import to execute.

      On the contrary, you'll see they both take exactly the same amount of time if you look more closely. The real value returned by time is a wall-clock figure, which doesn't represent the actual CPU time spent. The wall-clock figure will vary depending on what else the system was doing. The CPU time is the sum of the user and sys values - both of which are the same for the examples you gave.

      You'll find that most of the time in your example is taken up with the initialisation of python itself - so your statistics aren't very useful. I tried this test timing just the evaluations of the two versions of fact and found the reduce version to be consistently about 7 times faster than the recursive version. The reduce version also works for an arbitrarily large n (especially if you change the range to xrange in my earlier posting), and is a rather neat one line.

    7. Re:Why python? by rjh · · Score: 2

      I meant to say that this is the standard functional formulation of the problem.

      I still disagree with you. :) Most of the time when I want to write functional code, I write it in Scheme--so whenever I write functional code I have a very strong knee-jerk reaction to doing things with tail recursion, which is the standard way of doing it in Scheme. ;)

      I will grant that the two-liner I wrote was not the most obviously Pythonish in style, though. Just please keep in mind where I come from, functionally speaking.

      Python doesn't optimise the tail recursion away

      Feh. It should. Tail recursion is elegant. :)

    8. Re:Why python? by DrSkwid · · Score: 2

      or less than functional. :)

      it's procedural! I think that's enough evidence

      --
      There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
    9. Re:Why python? by Doppler00 · · Score: 1

      just a quick question about the rang() function. If you have a for loop with range(1000000) will it actually reserve that much memory just to do a long for loop, or is range interperetted like a counter?

    10. Re:Why python? by hoggy · · Score: 2

      just a quick question about the rang() function. If you have a for loop with range(1000000) will it actually reserve that much memory just to do a long for loop, or is range interperetted like a counter?

      If you use range then it allocates a list and populates it with the entire range of numbers requested. If you use xrange then it returns an object that implements the sequence protocol and looks like a list containing the appropriate range of numbers.

      So:

      for x in xrange( 1000000 ):
      print x

      is like a standard for loop counting through a million iterations. Whereas the range equivalent would have created a million element list and then iterated over that.

  6. Re:Why python? It's great (and so is C++) but ... by Anonymous Coward · · Score: 0
    ... these examples are all embarrassing. I'm sorry. The enthusiasm is right on, but please don't judge either language by these examples! Go to the official site at www.python.org and follow links in the Top Documentation section (reproduced here):

  7. Python Links by Anonymous Coward · · Score: 3, Informative
    Official site www.python.org

    Links in the Top Documentation section of the home page (reproduced here):

    You can wade in gradually, but you can also dive into deep water.