Python 2.4 Final Released

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

Comments

heh

[boschmorden]

import overlords

print "I for one welcome our new %s overloads.!" % overloads.get_random()

genexps

[ultrabot]

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.

Re:I *want* to be enthused, but...

[ultrabot]

after Linus's comments I am inclined to get more profficient with Bash and C and almost ignore Python completely. It's so dissapointing though - I really wanted to learn Python; it's such a neat language.

Linus explicitly mentioned that he doesn't do anything "in the middle" - it's either kernel hacking or something trivial enough to do with bash. Just go ahead and learn Python - you will find that it's *easier* than bash, especially if your programs might have errors (which they do).

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.

Go read ESR's "The Art of Unix Programming", available online for free.

Re:Pah

[Anonymous Coward]

python -c 'print "55 5 5";'

Re:Python is a pathetic language.

[tuffy]

I dare python lovers to write something like that in python in one line.

for f in glob.glob("/tmp/*").sorted(): print f

Though you will need to import glob in a seperate line. But I fail to see how doing trivial things trivially is a helpful measure of a language's usefulness.

Re:On Decimal and floating point

[Frequency Domain]

So, obviously, we should be using base (apply '* *n-first-primes*). How about 30 or 210? At least it's not an arbitrary base.

It doesn't matter which base you use. All your base are belong to us.

Re:CommonLisp for the 21st century?!

[geg81]

Python looks NOTHING like common lisp.

Python is a lot like CommonLisp: dynamic typing, reflection, eval, lexical scoping, extensive iteration and looping constructs, strings-as-sequences, and on and on.

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.

Go back and read the original papers on hygienic macros: you don't need Lisp syntax or code-as-data in order to have a macro facility as powerful as Scheme's (and Scheme got by for many years without macros anyway). I wouldn't be surprised if Python at some point gets a hygienic macro facility. Furthermore, there is a separate data syntax for Python that takes source that looks very similar to Python code and represents it as a DOM tree.

How do you return an anonymous function from a function in Python?

In the obvious way:

A ``def'' form executed inside a function definition defines a local function that can be returned or passed around. Free variables used in the nested function can access the local variables of the function containing the def.

That part is actually more natural than doing the same in CommonLisp (Python, like Scheme, but unlike CommonLisp, does not have separate value and function slots on symbols).

How do you build a function at run time? It's not easy or obvious.

There are two things you could mean by that. The first is to build it from source or structure. You can do this:

exec "def c(x): return x*x*x"

The second is to build complex functions using functions that take functions as arguments. You do that the same way you do in CommonLisp, since Python supports the same primitives: lexical closures, dynamic typing, and functions that take functions as arguments.

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

I think Lisp zealots incorrectly think nothing that isn't exactly Lisp could even come close. Python, in fact, is very close to Lisp; the two big differences are syntax and lack of macros. Lack of macros can be addressed, and there are separate Python-like syntactic representations of data.

Re:Is it just me?

[Jerf]

Or has python strayed from it's original philosophy of 'one best way to do it'?

To a degree, yes. Largely to the extent it has it is a result of backwards-compatibility; while the Python designers do not make the mistake of enshrining reverse compatibility above all else, they do try to avoid gratuitously compromising it.

As a result, as better ways to do things have emerged, sometime the old ways hang around and muss things up. However, for any given version there is always a "core" that you can stick to that is very close to "one best way to do it"... and despite what a first reading tells you, you really don't throw much of the language away.

For instance, while in modern Python you can say either

a = []
for i in range(5):
a.append(i*2)

or

a = [i*2 for i in range(5)]

the latter is the "one right way to do it". Few, if any, new additions truly leave you with two equally good choices.

(One of Guido's examples is the "lambda" statement, but a lot of people, including me, rather like not needing to replace

self.register("event", lambda event: self.keyPressed())

with

def handler(event):
self.keyPressed()
self.register("event", handler)

but hey, that's life. (While that isn't code for any GUI toolkit in particular that is a pattern common to all of them.))

By and large, none of these things have affected the difficulty of learning Python from scratch and using its libraries. It has affected the difficulty of reading other people's code, but I find the alternative, "keeping the language stagnant indefinately", completely unacceptable, and frankly, reading code is hard anyhow. (I was writing code for others long before I was reading other's code.)

In fact, given as that is the alternative, "keeping the language stagnant indefinately", while I concede it is somewhat sad that we can't jump to an optimal language immediately so that nobody ever has to learn anything past their first impression (not sarcastic, that would be the ideal), that doesn't seem to be working for folks. You might try LISP, though, I gather that hasn't changed syntax, much. (Though I also gather mature programs in that language tend to start looking like their own languages themselves, so that just may move the pain...)

python - awesome

[hashmap]

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.