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

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?

[Malcontent]

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.

Re:Platform Competition?

[archeopterix]

I'm really starting to think that the whole static type checking as a requirement for large systems thing is just dogma.

In fact, Java is a proof of that. Static type checking with most collections being Object holders? If you want typechecking, use a language with some decent type constructors (C++ templates will do, but ML-derivatives have much cleaner type systems). If you implement generics with Object, you defer typechecking till runtime, when your Objects get downcast to whatever you hope they really are.

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

[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

[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:Boolean support

[jdfox]

For simple flags, yes, "1" is quicker to type than "True". But Booleans can make other kinds of code clearer:

"For example, if you're reading a function and encounter the statement return 1, you might wonder whether the 1 represents a Boolean truth value, an index, or a coefficient that multiplies some other quantity. If the statement is return True, however, the meaning of the return value is quite clear."

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:Whitespace trolling...

[ProfKyne]

In general I find Ruby's way easier to read than Python's, especially in the case of weenies who haven't yet learnt to indent properly and have tabs/spaces randomly mixed in with their indents (a practice that seems so common as to outnumber the more traditional spaces OR tabs methods many times over).

Interesting... seeing as how Python doesn't let weenies indent improperly, and you can run Python scripts with a flag (-O) that gives warnings if tabs and spaces are intermixed in the whitespace... you would think that Python's way would be easier.