Python 2.3 Final Released

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

Comments

Countdown to Gentoo zealotry.

[Anonymous Coward]

In 3... 2... 1...

Python 3

[Alan Holman]

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

[Omicron32]

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

Re:Whitespace trolling...

[BigJimSlade]

What's wrong with { and }?

What's wrong with it is that it's the syntax for dictionaries. Similar to hashes in Perl, it is a built-in type for Python. Anything wrapped in {} would probably be viewed as an attempt to make a dictionary by the parser.

I've discussed this with all my software engineering colleagues, and most of them have white space as their only hang up about the language. I thought this was pretty petty at first, given the other strengths of the language, but one person brought up an extremely good point. A co-worker at his company is blind. He said that having to deal with white space while coding was near impossible (maybe he uses a "pretty printer" or code beautifier after the fact? I don't know) Has anybody on /. had experience with a blind user of Python? How did they work around this issue (if at all?)

I do think it would be nice if there was a way to open and close a block (someone later down in the comments suggested preprocessor comments of

#begin

and

#end

) such that one could use either method. Perhaps there would even be a built in function of the interpreter to spit out the code one way or the other.

I must say I've gotten used to the whitespace over the past year. Using a decent editor makes life much easier in this respect. I would encourage anyone who hasn't tried out Python for this reason alone to give it a shot for a few weeks and see what you think.

question to practical programmers

[Maimun]

At the top of the list of new features they have sets. 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.

Re:question to practical programmers

[jcr]

I suspect that most time-critical code is not written in python.

Depends on which time is critical: CPU time, or programmer time?

-jcr

Re:question to practical programmers

[elflord]

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:Reviewing a book 101

[Sir Haxalot]

Ask any Python aficionado and you'll hear that Python programmers have it all: an elegant language that offers object-oriented programming support, a readable, maintainable syntax, integration with C components, and an enormous collection of precoded standard library and extension modules. Moreover, Python is easy to learn but powerful enough to take on the most ambitious programming challenges. But what Python programmers have lacked is one concise and clear reference resource, with the appropriate measure of guidance in how best to use Python's great power. Now Python in a Nutshell fills this need.

In the tradition of O'Reilly's "In a Nutshell" series, this book offers Python programmers one place to look when they need help remembering or deciphering the syntax of this open source language and its many modules. This comprehensive reference guide makes it easy to look up all the most frequently needed information--not just about the Python language itself, but also the most frequently used parts of the standard library and the most important third-party extensions.

Python in a Nutshell focuses on Python 2.2 (and all its point releases), currently the most stable and widespread Python release. This book includes:

A fast-paced tutorial on the syntax of the Python language itself

An explanation of object-oriented programming in Python, covering both the classic and new-style object models

Coverage of other core topics, including exceptions, modules, strings, and regular expressions

A quick reference for Python's built-in types and functions, as well as the key modules in the Python standard library, including sys, os, time, thread, math, and socket, among many others

Reference material on important third-party extensions, such as Numeric and Tkinter

Information about extending Python and embedding it into other applications

Python in a Nutshell provides a solid, no-nonsense quick reference to information that programmers rely on the most. This latest addition to the best-selling "In a Nutshell" series will immediately earn its place in any Python programmer's library.

Synopsis
In the tradition of O'Reilly's "In a Nutshell" series, this book offers Python programmers help remembering or deciphering the syntax of this open source language and its many modules. This comprehensive reference guide should make it easy to look up all the most frequently needed information - not just about the Python language itself, but also the most frequently used parts of the standard library and the most important third-party extensions. The book includes: a fast-paced tutorial on the syntax of the Python language itself; an explanation of object-oriented programming in Python, covering both the classic and new-style object models; coverage of other core topics, including exceptions, modules, strings, and regular expressions; a quick reference for Python's built-in types and functions, as well as the key modules in the Python standard library, including sys, os, time, thread, math, and socket, among many others; reference material on important third-party extensions, such as Numeric and Tkinter; and information about extending Python and embedding it into other applications.

Happy? :)

Platform Competition?

[Chromodromic]

Check out Artima 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, 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, 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 is looking more and more attractive for quite a number of things.

Download soon and often.

Re:Platform Competition?

[wdr1]

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?

[GooberToo]

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.

Its 20-30% faster !!

[vivek7006]

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

[elflord]

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

[ansible]

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

Re:Its 20-30% faster !!

[elflord]

If it were possible to compile Python (or any other interpreted language), would this make it anywhere near the speed of C/C++?

Compiling alone wouldn't bridge the gap. Python already reduces interpreter overhead by using a pre-compiled byte-code. A large part of the problem is in dynamic typing: for example, when you say
a+b
in python, it's not equivalent to doing the same in C++. In python, you need to do a runtime type check and then decide what operation to perform, and only then can you add a and b. In C++, the dispatch can be performed compile-time.

What you really need to get a big speedup is some sort of mechanism that can eliminate a lot of this type checking (the other guy posted a link to an interesting approach to this problem)

But I've often been impressed with the ease of coding in such a language

It's a bit of a two-edged sort for the same reason -- the lack of type checking makes it easy to write code quickly, but it also makes it easy to code incorrectly.

Re:Why Python is good at our university

[The Bungi]

He's a troll. "Fu-Ling Yu" Get it? Haha and all that. He just pastes some links from the quoted article and get modded +5 with alacrity because of his charming "engrish". The stupid mods always fall for it.

Better than Learning Python.

[Big Sean O]

Learning Python is getting quite dated (it covers Python 1.5). I recommend Python: A Visual Quickstart Guide by Chris Fehily. It's a better book than Learning Python, at least.

I've been learning Python Language for a while, but since I don't work with other programmers, it's taken me quite a while. I learned python the usual way (a mix between the on-line tutorial and Learning Python) and my fluency is improving.

I picked up this book recently while I was at a convention in Baltimore. I liked its organization: the book features a whole chapter on each datatype (strings, numbers, tuples, lists, and dictionaries). There are also chapters on Control Flow Statements, Functions, Modules, Files, Classes, and Exceptions.

Because of its organization, it's as useful as a reference as it is a tutorial. Each chapter contains progressively advanced examples that end up demonstrating the finer points of each topic.

For example, one hint was to use the vars() function creates a dictionary of the local namespace. This makes it useful when string formatting:

>>> quality = 'color'
>>> thing = 'orange'
>>> print "What %s is an %s?" % (quality, thing) # useful for simple formatting.
What color is an orange?
>>> print "What %(quality)s is an %(thing)s?" % vars() # more legible and useful.
What color is an orange?

The book does not cover advanced topics like Tkinter, Jython, or extending Python with C. Nor does it cover the Library modules (the Python online documentation is actually quite good).

"Python" is newer, cheaper (22 USD vs. 30 USD), and longer (410pp vs. 368pp) than "Learning Python"

I would recommend this book to anyone who would like to learn Python. If you're an intermediate Pythoneer, I agree with the parent: you will want to get "Python In A Nutshell".

Re:I see whitespace is still syntactically relevan

[wass]

There's a feature I'd like to see removed.

I hear this repeated fairly often, but I can not think of any really good reason why whitespace is bad. IMHO, any decent programmer worth his/her salt will whitespace their code anyway for sanity.

Just to be my own devil's advocate, here are some reasons I can think of off the top of my head. But I don't think any is sufficiently great for not using python strictly because of it's required whitespace syntax.

Actually, I want to become proficient in python, I've even got a few books, and just haven't gotten around to programming any application in it yet :-( But these are things I've wondered about (regarding the whitespace). Hopefully a seasoned veteran can point out why these aren't substantial problems.

• Putting a large block of code into a while or for loop.

  In C, if I am quickly hacking some stuff together and realize I want to put 100+ lines into a for loop, I can put brackets around the code and possibly indent it later if I wind up keeping the code for long-term.

  In python I'd have to manually go to all those lines and put the indent in. (I assume EMACS and other editors can do this automatically, if one knows the key combinations).

• TABS and order of whitespace

  This confuses me. Does python keep track of instances of \t in an input file? Are they distinguishable from spaces? If at some nested level of indentation I'm at [tab][space][space], is a line of indentation of [space][space][tab] at the same nesting level?

  If I'm at [space][space][space][space] can the next level of nesting be [tab]?

• For decently-complex programs there might be so many nesting levels that the indented code is spaced so far inwards that one needs ridiculously-wide displays for sanity.

  Personally, I don't think I've ever put more than 10 levels of nested blocks in a program somewhere, but I suppose it could possibly happen and might be a problem, especially of someone is restricted to 80-column screen for some reason.

Other than those rare or obscure issues, I can't think of any reason that mandatory whitespacing should hold someone back from python.

Re:I see whitespace is still syntactically relevan

[Anonymous Coward]

There'safeatureI'dliketoseeremoved.Iguessit'sGui do'swayofjustbeingdifferent.

Isn't that better?

No cookie for you.

Re:I see whitespace is still syntactically relevan

[jericho4.0]

For your first two points, a decent IDE helps a lot, or just being familiar with your editor of choice. It's much easier to figure out the key combo in emacs/vi than it is to indent 50+ lines.

For your second point, 10 levels of nesting is, IMHO, at least 7 too many. That's what subroutines are for. If you find yourself adding another level after three, it's probably time to look at your design.

Re:I see whitespace is still syntactically relevan

[Ian Bicking]

Putting a large block of code into a while or for loop.

Editor support is very useful in this case. In Emacs you can indent/dedent a region with C-C > and C-C < (i.e., control-C, then > or <); you mark a region by going to one end, hitting C-space, then putting your cursor at the other end (or dragging with the mouse).

TABS and order of whitespace

Python treats all tabs like 8 spaces, no matter the location. But mixing tabs and spaces is considered bad and potentially dangerous if you display tabs as something other than 8 spaces. You can use the -t flag to Python to warn you about this.

Discussions on tabs and spaces can lead to flamewars in Python circles. Many people hate tabs, and a significant majority of code does not use tabs.

As far as screen width, that's no different in Python than any other language. Deep nesting is a sign of a program in need of refactoring.

Shameless plug

[Lulu of the Lotus-Ea]

Alex Martelli has indeed written an excellent book. Actually, he almost wrote two excellent ones, since he is co-editor of _Python Cookbook_ too (but the latter is really more of a collaboration of dozens of people in the Python community than a book by an individual).

However, my book, _Text Processing in Python_, has at least one think over Alex's that is germane to this thread: I make a good effort to cover Python 2.3. I am quite confident that mine is the only book you can actually buy today that does so (I'm sure there will be more titles, and various updates, over time, of course). Don't let my title fool you, btw, I do a bit more than the title entirely admits to. But the title isn't a lie either, it really is focussed on the broad area called "text processing".

Anyway, there's nothing subtle in my plug. I really will get a couple dollars every time someone buys one (unlike the somewhat odd insinuation downthread about Sir Haxalot doing so). But then, I also invite everyone to read the entire text for free at:

http://gnosis.cx/TPiP/

So you can have something for nothing too, if you want.

David Mertz

Re:I see whitespace is still syntactically relevan

[Cranx]

The reason I never bothered with Python is because of the whitespace issue, and I'll tell you why:

I don't trust that blocks are properly grouped.

When I program in C++, Java or even Ruby, and I create a new block, the first thing I do is close the block. Any code I put in the block I indent, but if the block grows, or my indenting gets goofy, I don't have to fear that my block is now improperly closing.

If I paste in a few quick lines of code for debug purposes, and it just happened to be indented differently than where I was pasting it, that would screw up the block closure unless I went and tabbed everything correctly. Sometimes, I *like* that the temporary code is indented wrong because it helps remind me to comment it out or remove it when I'm done debugging.

The whitespace thing is just too weird. It generates a lot of feelings that I might screw up my blocks. That sort of anxiety shouldn't be there; I shouldn't be so worried about blocks closing.

Re:ATTENTION!

[larry bagina]

Upgrading to Python 2.3 will _not_ increase your skill levels, and will NOT make your AOL downloads faster!

Actually, it could. The PHP crowd blew every horn they could find when yahoo switched over to PHP, but AOL has been using python behind the scenes for a long time with little fanfare (or problems). So if it's AOL doing the upgrading, it might help your AOL downloads be faster.

Re:definately?

[joe_bruin]

your new hear, i take it.
we definately do not waist are time with speling and grammer, you looser.

in the immortal words of homer*:
"if i spelled cat 'C', 'A', 'T', you'd know what i mean"

* simpson, homer j. not that other guy.

Python is actually strongly typed.

[XNormal]

Python is definitely not typeless. It's actually strongly typed. But it uses dynamic typing.

Take a look at this article for clarification on typing models.