Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Python 2.3 Final Released 371

Posted by timothy from the new-snake-in-town dept.
An anonymous reader writes "Nineteen months in the making, Python 2.3 has just been released. With a plethora of changes since version 2.2, this release is definately worth the upgrade. Be sure to read the Release Notes and the Highlights file for more information."
This discussion has been archived. No new comments can be posted.

Python 2.3 Final Released More

Python 2.3 Final Released

Comments Filter:

  • impact... (Score:2, Interesting)

    by alienhazard ( 660628 )
    I wonder what this means to the people at blender [blender.org] who just updated the python API

    • Re:impact... (Score:3, Informative)

      by sketerpot ( 454020 )
      Pthon 2.3 was designed with backward compatibility in mind. All your old programs should work with 2.3 if they work with 2.2.2, and you'll get some speed improvement. Of course, if you use 2.3-specific modules like logging (based on log4j) and sets (set operations, using dictionaries internally), those won't be compatible with 2.2.2 unless you copy the files from the standard library, which should work.

      In short: don't worry about it. The python developers already have.

  • Countdown to Gentoo zealotry. (Score:4, Funny)

    by Anonymous Coward on Tuesday July 29, 2003 @08:42PM (#6566347)
    In 3... 2... 1...

  • Python 3 (Score:5, Funny)

    by Alan Holman ( 607935 ) on Tuesday July 29, 2003 @08:42PM (#6566348) Journal
    Wow, finally Python 3! Are they as good as the original Monty Python? I didn't see the second Monty Python...Err... Is John Cleese still in Python?

  • Whitespace trolling... (Score:5, Funny)

    by Omicron32 ( 646469 ) on Tuesday July 29, 2003 @08:45PM (#6566370)
    I'm just waiting
    for the trolls to start
    complaing about
    whitespace usage in
    Python.

    That, and what does this mean for improvments to my favourite distro's package management? (Gentoo!)

    • I honestly doubt it's gonna have any noticeable effect on portage. Or maybe it will. Python 2.3 now has a great logging package built in :)
    • trolls=[post for post in posts if post.complains(whitespace)]

      USE="brains" emerge joke

    • Don't you mean?

      def waiting (trolls) :
      for troll in trolls :

      complain(troll, whitespace_usage)

    • Python:
      Programming the way
      Guido
      indented it.

  • question to practical programmers (Score:5, Interesting)

    by Maimun ( 631984 ) on Tuesday July 29, 2003 @08:53PM (#6566444)
    At the top of the list of new features they have sets [python.org]. The first paragraph says that sets are implemented by hashtables. I wonder whether it is really meaningless from the "practical" point of view to implement sets with data structures like red-black trees or Fibonacci heaps. The advantage of the latter over hashtables is a solid bound on the worst case running times.
    • Essentially, hash tables are preferred over balanced trees because they are usually faster in practice.
      [google.com]
      Python developer showing preference to hash tables over balanced tres.

      I would also like to see balanced trees in the library, if for nothing more than sometimes ordered iteration is more useful than fast lookup, but oh well. I believe having hash tables but not balanced trees is much less bad than the other way around (like standard C++), in which there are balanced trees but no hash tables.
    • The advantage of the latter over hashtables is a solid bound on the worst case running times.

      Another key advantage, is that RB trees are automatically sorted.

      I'd suppose they use hashtables because they're interested in good average case performance, especially for large tables. I doubt they'd care about worst-case performance -- I suspect that most time-critical code is not written in python.

      • Comment removed (Score:5, Insightful)

        by account_deleted ( 4530225 ) on Tuesday July 29, 2003 @10:35PM (#6567134)
        Comment removed based on user account deletion

        • Re:question to practical programmers (Score:4, Insightful)

          by elflord ( 9269 ) on Tuesday July 29, 2003 @11:33PM (#6567494) Homepage
          I wasn't trying to dis python, but the point is that most python programmers (even the ones who are interested in performance) are probably thinking "I want this to be as fast as possible on average", not "someone (possibly the programmer) will die if this code does not run in 0.05ms. In one case, you're interested in average case performance, in the other you're interested in worst-case.

          For most web applications, you only care about average case, but for embedded systems, medical equipment, air traffic control systems, etc, worst case may also be very important.

          • Re:question to practical programmers (Score:4, Interesting)

            by Ed Avis ( 5917 ) <ed@membled.com> on Wednesday July 30, 2003 @06:48AM (#6569255) Homepage
            After the recently-implemented algorithmic complexity attack against many hash table implementations (story on Slashdot a couple of months ago), many more programmers have reason to be concerned about the worst case. If you are hashing inputs taken directly (or perhaps even indirectly) from the user, then by choosing the right strings an attacker can DoS your system by making lots of hash collisions, so each lookup becomes effectively a linear search.

            I don't know what Python (or other scripting languages) are doing to address this; many on the Python newsgroup seemed not to care and said that the operating system should deal with any process which is using too much CPU time, but I don't know if this attitude is shared by the real Python developers.

            Perhaps for security-conscious applications you could choose to use red-black trees or some other implementation of associative arrays, at least in cases where strings sent by the user are used as part of a hash key. Perhaps Perl's tainting mechanism could help with this.

      • I'd suppose they use hashtables because they're interested in good average case performance, especially for large tables. I doubt they'd care about worst-case performance -- I suspect that most time-critical code is not written in python.

        If the code is not time-critical then why optimize for average case performance?

      • Another key advantage, is that RB trees are automatically sorted.

        Most stl map implementations are based on a RB tree, and often cause memory fragmentation. That's not the end of world for most programs, but data being located on many different pages can trash average access times for threaded programs (although constant use of the memory allocator probably harms the program itself more).

        A hash gives good memory locality and good average lookup performance, if data is constant (or near constant) a sort

        • If you want to see an interesting container implementation (based on a trie, behaves like a hashtable) check out Judy Arrays [sf.net]. Judy is bogglingly complex, but it boils down to optimizing for the CPU cache.
          Judy looks fairly promising for some applications I'm looking at. The benchmarks I ran are sort of bogus though since I'm not causing fragmentation by doing other things between inserts and deletes. I suppose the moral of the story is, preallocate if you know your structure is going to get big.
    • I believe the reason is that sets in Python are implemented [sourceforge.net] in the Python language itself. Since Python already has hash tables implemented in C, it was easy to write a good set class by using a hashtable. To get the same level of performance with another data structure would mean writing and maintaining a bunch of C code.

      The Python developers could always rewrite the set class in C using Fibonacci heaps at some later time. By writing it in Python, they get a reasonably good implementation now where peo
  • Not, necessarily from this particular release, but in general the whole objective/functional thing which Python is doing really is very interesting and ought to be pushed further.

    Some way to use Perl libraries would really kick ass too but I guess that's impossible without Parrot coming into reality.

  • Platform Competition? (Score:5, Insightful)

    by Chromodromic ( 668389 ) on Tuesday July 29, 2003 @08:56PM (#6566473)
    Check out Artima [artima.com] if you want to see Bruce Eckel's take on the Python language which, incidentally, with the addition of things like a logging API, and with long-existing additions like Jython [jython.org], is beginning to look more and more like a viable competitor to Java.

    Why?

    Python carries a LOT of the same advantages, but with a dramatically accelerated prototyping and general development speed, and a few tricks of its own. Plus, via Boost [boost.org], it interoperates with C++, too. I'm an avid Perl hack, but I have to admit that Python, which even has a whole API for basic game programming [pygame.org] is looking more and more attractive for quite a number of things.

    Download soon and often.
    • [Python] is beginning to look more and more like a viable competitor to Java.

      Python is a great scripting language and development in it is much easier than in Java, but it is not a competitor to Java. Java achieves close to C/C++ performance on low-level code (for loops, arrays, etc.); Python doesn't even get close. That really matters in many applications because it means you don't have to "drop down" to C. And Java has static type checking. Static type checking is a nuisance for prototyping, but it i
      • Maybe you are right but I have written several apps in python and java, and the ones in py left java in the dust. Much less memory for the runtime too.

        • Re:Platform Competition? (Score:5, Interesting)

          by GooberToo ( 74388 ) on Wednesday July 30, 2003 @12:06AM (#6567712)
          This is a common saying when you talk with Python/Java programers. Plus, with something like wxPython, you can have a slick client application to boot.

          Last time I saw unbiased performance comparisions, the difference between Python and Java wasn't really worth talking about.
        • Maybe you are right but I have written several apps in python and java, and the ones in py left java in the dust. Much less memory for the runtime too.

          There is no contradiction: the Java libraries and the Java runtime have numerous design flaws that cause people to build bloated and sluggish applications in Java. In fact, the same can be said for many C++ frameworks.

          But if you just look at the languages and their implementations, it's easy to compile Java into tight, efficient machine code, while the sa

      • Re:Platform Competition? (Score:5, Funny)

        by wdr1 ( 31310 ) * <wdr1&pobox,com> on Wednesday July 30, 2003 @12:01AM (#6567677) Homepage Journal
        ava achieves close to C/C++ performance on low-level code (for loops, arrays, etc.); Python doesn't even get close.

        Wait, now Java people are saying other languages are too slow?? ;-)

        -Bill

    • Re:Platform Competition? (Score:4, Insightful)

      by Malcontent ( 40834 ) on Wednesday July 30, 2003 @12:03AM (#6567686)
      It seems to me that everything Bruce praises about python also applies to most other dynamic typed scripting languages. Certainly ruby and even php or dare I say it perl.

      He seems more in love with the idea of typeless, brief, dynamic and expressive languages in general. it's just that he learned python first and has gotten good at it. If he picked up Ruby first he would be saying the same things about it.

  • Its 20-30% faster !! (Score:5, Insightful)

    by vivek7006 ( 585218 ) on Tuesday July 29, 2003 @09:00PM (#6566500) Homepage
    According to a couple of simple benchmark, Python 2.3 is about 20-30% faster than Python 2.2.3. Some of this speed-up was obtained by removing the SET_LINENO opcodes, which means that the difference is less impressive when comparing "python -O"; the rest was various careful tune-ups.

    This is a big improvement. The biggest advantage of using a programming langage like python is the fast development time (5X-10X faster than C++). If the speed of execution of python scripts can be made comparable to compiled C/C++ code, then it would be awesome. Python programs can never be as fast as compiled code, but if the difference in the speed is not significant, it will be a big win for Python

    • Re:Its 20-30% faster !! (Score:5, Informative)

      by elflord ( 9269 ) on Tuesday July 29, 2003 @09:20PM (#6566659) Homepage
      If the speed of execution of python scripts can be made comparable to compiled C/C++ code, then it would be awesome.

      Out by an order of magnitude, and not getting closer any time soon. Last I checked, it's out by a factor of 100 or so for small operations (loops, etc) But this isn't a problem in practice -- one can code the speed-critical stuff (whether that be objects, or functions) in C or C++, then wrap them in python, and enjoy all the benefits of python.

      Also, it often happens that 1% of the speed of C and C++ is actually good enough. Sounds slow, but only compared to C and C++ which may be well over 100x faster than what's required.

      Python programs can never be as fast as compiled code, but if the difference in the speed is not significant, it will be a big win for Python

      It is much slower, and unavoidably so. It's a very dynamic language, and this has consequences as far as performance is concerned.

      • Re:Its 20-30% faster !! (Score:5, Interesting)

        by ansible ( 9585 ) on Tuesday July 29, 2003 @11:16PM (#6567378) Journal

        Out by an order of magnitude, and not getting closer any time soon. Last I checked, it's out by a factor of 100 or so for small operations (loops, etc)

        Well, regular Python code can see some dramatic speedups, with just a little bit of extra work. Check out Psyco [sourceforge.net] if you firmly believe that interpreted languages will never ever be as fast as C.

        With sufficient cleverness, it may be possible to boost Python beyond the speed of the most highly optimized pre-compiled program.

        Psyco and approaches like it do have drawbacks, but there is some very interesting work going on now with high-level languages.

        • Check out Psyco if you firmly believe that interpreted languages will never ever be as fast as C.

          Or you could use Common Lisp, and realize that you're a few years behind....
      • Psyco has been already mentioned. Another interesting approach to opptimising python code (only if and where it is too slow) is Pyrex" [canterbury.ac.nz]. Unlike Psyco,it requires small changes (adding some type information) to the code of the python modules you want to optimize, and then produces an equivalent (but faster) C module.

        Still a work in progress, but interesting.

    • Re:Its 20-30% faster !! (Score:4, Informative)

      by jgardn ( 539054 ) <jgardn@alumni.washington.edu> on Wednesday July 30, 2003 @12:03AM (#6567687) Homepage Journal
      Python is running on a virtual machine that uses a stack. This is what pretty much every high level modern language does, including Perl and Java.

      However, with the addition of Parrot, Python, as well as Perl, will be running on a virtual machine that uses registers rather than a stack. Register based machines are much faster than stack based machines.

      Damian Conway, in a presentation at the Seattle Perl User's Group, demonstrated that you can actually get code that is written in perl that runs only a small factor (like 4 or 5 times) slower than C, rather than many orders of magnitudes (like 100 or 10,000 times) slower. This speedup will benefit Python as well, when it is ported to Parrot.

      In short, Python and Perl, and every other language that is ported to Parrot, will kick some serious butt, and put a lot of C programmers out of work.
  • Booleans in Python at last, hurrah. We should see Boolean support appear in Jython soon too then, and an end to fiddling with 0's and 1's.

    • Booleans were added sometime in 2.2... 2.2.2 I believe. But yes, very handy. :)
      • Booleans were added sometime in 2.2... 2.2.2 I believe. But yes, very handy. :)

        2.2.1 added True and False constants, which were set to integer 1 and 0.
        But 2.3 adds a true Boolean type [python.org].

  • Some of these features look useful enough but the one that stands out most as having a minor problem is importing modules from zip archives. That's all well and dandy but why not also support from other archives? tar + gzip or bzip would get better compression. The syntax looks like it could be a little clearer. Why not just 'import example.zip/mymodule' instead of messing with sys.path.insert() ? That sounds cleaner to me.
  • Bastion and rexec - these modules are disabled, because they aren't safe in Python 2.3 (nor in Python 2.2). (New in 2.3a2.)
    Uh oh. What's unsafe about Bastion in 2.2?
  • I'm looking forward to playing with the datetime module. The old C-based API is just gross.

Slashdot Top Deals

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Close