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

18 Months

[nijk]

It took them a while, but it's worth it. Here's some of the new features:

* multi-line imports - when using imports in the form from foo import bar, baz, bing, bang, you can surround the imported names with brackets, and they can be split across lines. This is part of PEP 328.
* Farewell to OverflowWarning - as documented in PEP 237, Python no longer generates OverflowWarnings.
* function/method decorators - function and method decorators, first described in PEP 318, have been added to the language, using 'pie-decorator' syntax. Decorators are on the line before the 'def', and prefixed with an '@' sign. (PEP 318)
* Assigning to None - the compiler now treats assigning to None as a SyntaxError.
* Failed import cleanup - when a module import failed, versions of Python prior to 2.4a2 would leave a broken module in sys.modules - subsequent attempts to import the failing module would silently succeed, but use the broken module object. The import machinery now removes the failing module from sys.modules if the import fails.
* The -m command line option - python -m modulename will find a module in the standard library, and invoke it. For example, python -m pdb is equivalent to python -m /usr/lib/python2.4/pdb.py

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

[Anonymous Coward]

Someone elaborate a little? Maybe even give us a link?

Re:genexps

[percivall]

Yeah, generators do kick ass.

But it's important to remember that generator expressions are slower than list comprehensions. This is mainly because functions calls are expensive in Python, and when dealing with generators each iteration means one more function call.

Re:Is it just me?

[Anonymous Coward]

python did not remove the easy way of doing things, the newbies can still use the simple syntax to get a lot done, and those who know a lot more can use the advanced features.

segmond

Use a toolkit

[gregarican]

There are GUI toolkits which typically are added on as an extension to something like Python. I am learning Ruby and can choose from Qt, Tk, Wx, Fox, etc. As long as someone has created the extensions you are good to go.

Re:Is it just me?

[Anonymous Coward]

It's not just you.

The "eye opener" for me was reading the Python cookbook. Almost every recipe listed 2-3 ways to do everything, most of them hard to understand and using Python "tricks". Many of them depended on new 2.x features. I realized that there are now two kinds of classes in Python for instance.

The Python community has also grown arrogant like the Perl community. If a newbie writes something that can be re-written with a list comprehension for instance, it's pretty much given that nobody will actually answer his question, choosing instead to re-write his program for him using tricks and shortcuts.

I'm using Ruby almost exclusively for new projects and it just kicks Python's ass up and down the street. Simple, orthogonal, consistently designed to *begin* with, easy to read, small and friendly community.

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:Writing extensions...

[imroy]

The Boost [boost.org] project has Boost.Python [boost.org]. I haven't used it yet, but the docs make it sound very interesting. It looks quite simple to write base classes in C++ and then subclass them in Python.

Re:Use a toolkit

[Stradenko]

http://www.python.org/cgi-bin/moinmoin/GuiProgramm ing [python.org]

Re:Sets in Python

[tuffy]

Sets can operate on anything. But you need to pass in a list of those things to build a set out of, such as:

>>> s = sets.Set(["foo","bar"])
>>> s
Set(['foo', 'bar'])
>>> 'foo' in s
True

Re:OK Trolls...

[pclminion]

Do you really want to go through each line, scrolling all the way to the end because your language has significant whitespace?

There is absolutely nothing that says you can't break things across lines. In most cases you don't even need a backslash to escape the linebreak. TRY the damn thing before criticizing it.

Re:Writing extensions...

[William Stein]

One can write extensions in Pyrex [canterbury.ac.nz], which is a language that is very similar to Python. Pyrex code is converted to C, which is ccompiled into an extension to Python. One can also access any C libraries from Pyrex.

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

[Lumpy]

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.

nice try.

C is the defacto for embedded systems. it's smaller and faster and there are libs available that make your app 1/10th the size of a regular C app.

ther are no embedded libs for C++ that are solidly tested and compatable with the regular libs.

Embedded programming is getting huge, and C is a part of that.

Re:Writing extensions...

[loqi]

I've done a fair amount of work with Boost.Python, and I've been quite happy with it. It used to be a bit tedious to wrap classes with polymorphic behavior, but one of the Boost.Python contributors has written a program (Pyste) to automatically generate Boost.Python bindings. It's not always what you need, but it's flexible enough to be very usable.

Re:Supprised

[eli173]

From the little I have seen, python seems to be a command line language. Is it anywhere similar to Visual Basic, which I have come to see and experience through a GUI?

Check out tkinter and wxPython.

And if you like KDE, checkout PyQt [riverbankcomputing.co.uk].

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:I *want* to be enthused, but...

[Anonymous Coward]

If you want to be a good programmer all-around you _have_ to know C.
[...]
Other than these - it's a very cool, easy to learn, and elegant language. One of inventors - I don't remember who - Ritchie? - said that if he had to invent it anew, the only change would've been "creat()" becoming "create()"

That was a comment about UNIX, dumbass. It's amusing that you made a comment about needing to know C, but you apparently don't know C well enough to recognize that "creat()" is not a part of the C language.

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

Re:Not a Python Programmer...

[percivall]

The feeling was that it was unnecessary since metaclasses already provide the functionality that class decorators would have provided.

For those of you who aren't Python programmers: Metaclasses are to classes as classes are to instances. At compile-time (at runtime) the metaclass constructor is given the newly created class object for initialization. This provides the possibility for manipulation and more.

Re:genexps

[ultrabot]

It seems like 90% of these are created because lamdba sucks and def isn't anonymous.

Uh, you do realize that generators have nothing to do with anonymous functions, and that it's rather a simplified, understandable approach for providing coroutines? Generators are significantly more powerful than Ruby code blocks.

Re:Not a Python Programmer...

[Ian Bicking]

I was also stunned to learn how flexible decorators were in the previous version of python. It's refreshing to be see functions treated as objects... unless I'm mistaken about the concept.

Another important part has been Python 2.2's new-style classes and descriptors [rcn.com]. Descriptors are basically objects with special methods (__get__, __set__, __delete__). When you access a class or instance attribute, instead of returning the descriptor, the a method of the descriptor is called. This is what allows classmethod, staticmethod, and property, but also a number of other declarative techniques for class definitions. Well, it's one of several things that work together to create interesting new possibilities in Python.

Re:frozenset

[Anonymous Coward]

in short, no.

python doesn't have modifiers for anything else, so it would require syntax changes. Whitespace after a python reserved word seperates it from its expression.

"frozen x = Set()" complexifies things because since day 1, an assignment returns 'None', and 'frozen None' is nonsense.

You could of course write it as a property:

x = Set()
x.become_frozen()

But it's better to consider 'frozenset' as a subclass of 'set' (or vice versa), since 'frozenset' very well fits the 'is a' paradigm, because a frozenset IS A type of set!

Re:Supprised

[Anonymous Coward]

I think he meant *through* a GUI, not "make a GUI".

There's plenty of python "dev studio" things. The latest kdevelop supports it natively, and there's also 'idle'. thekompany produces 'blackadder' too.

There's loads of other half-arsed attempts at creating a nice gui, and probably some full-arsed ones that I've not thought of.

Re:sigils sneaking in

[jkujawa]

Done. [python.org]

Re:Supprised

[Junks Jerzey]

Can one tell me why I should learn python and not any other programming language anyway?

I expect this isn't the answer that true Python devotees would express, but here goes anyway: It's a very high-level, very dynamic, language that's reliably cross-platform.

"Very high-level" differentiates it from Java, which I see as more mid-level. It's also different than Perl 5, which is higher-level than Python in some ways, but convoluted and crusty in other ways (anything involving nested data structures, for example).

"Dynamic" means you can test code interactively, you don't a build process, you don't waste time enumerating things and creating redundant headers and so on.

"Reliably cross-platform" is the key. This is where Scheme and Lisp and Haskell fall down. Lisp has a standard definition, but the community is fractured by there not being a standard implementation. You can argue that diversity is good and all that, but it does tend to hurt overall. Python has a huge number of standard library modules as a result.

Re:genexps

[poincaraux]

Also, iterator and generator resumption is faster than a function call.

Yup. Like the PEP [python.org] says,

Early timings showed that generators had a significant performance advantage over list comprehensions. However, the latter were highly optimized for Py2.4 and now the performance is roughly comparable for small to mid-sized data sets. As the data volumes grow larger, generator expressions tend to perform better because they do not exhaust cache memory and they allow Python to re-use objects between iterations.

I think I know where the OP got the idea that genexps would be slow .. function calls are slow in Python .. in things like for loops, but not in places like genexps and maps. It's a good idea to test something out before you make claims about its speed.

BlackAdder

[kinema]

Many of these things can be found in other languages as well. So it largely comes down a matter of preference.

Check out tkinter and wxPython.

What about BlackAdder [thekompany.com] from theKompany [thekompany.com]? I've never used it but I would love to hear from those that have.

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

[abdulla]

If you're going to nitpick about how man CPU instructions it takes to return a std::string, you better not use any high-level language.

Take a look at the job market, good knowledge of C++ is still an invaluable skill.

Moreover take a look at libraries like boost [boost.org] or systems built on C++ like KDE. Well written C++ can be just as elegant as any language (it's always in the programmers hands, they can turn anything in to spaghetti). There's a reason why it's been so popular and many of its concepts are used in other languages (not to say that it was original in its ideas, but in its use of them).

Re:Numerical programming needs an array type

[geg81]

Any serious numerical programming needs an array type. List types based on indirection, whether from Lisp or Python just don't do the job -- too much overhead.

Python "lists" are extensible 1D arrays; there is no extra indirection.

Python is working on arrays -- Numeric and Numarray -- but adoption seems slow in stuff like plot and graphics packages.

Numeric and Numarray are widely used by people who need them and they are great and mature packages. But I think the fact that they aren't used universally is deliberate: if their performance and/or functionality isn't needed for a particular application, it's probably better to stick with regular Python lists to keep things simple.

I would like to use Python as a replacement for Matlab -- I am bothered that we are so stuck on Matlab in our engineering curriculum -- a university shouldn't be shilling for a properietary language from a single vendor. Besides, Matlab is so ad hoc and cobbled together -- I think we could use something with a better theoretical foundation in language design.

I fully agree there. And the way to make that happen is to create more packages. I am writing numerical Python packages and making them available publicly. The more people do that, the sooner we can replace Matlab.