An alpha version of Python 2.4 can be downloaded here. Here's what's new: - Built in set objects (like c++'s std::set), allowing for quick union/intersection/difference operations. Useful for storing a character's inventory or possibly for handling collision detection. - unification of ints and long ints, meaning you have pretty much no restriction on the size of integer values. (Watch out for the implications to bit-level operations though.) - generator expressions, which are like list comprehensions/expressions except which return a generator that feeds you one item at a time, rather than creating an intermediate list. This will reduce memory consumption especially when processing large data sets. - reverse iteration over a sequence with the 'reversed' function - decimal data type to handle floating point values without the typical floating point inaccuracies, mainly good for currency calculation - list.sort() upgraded to allow sorting in reverse order, or sorting based on an alternative key value for each object (faster than providing a new comparison function) - sorted() iterable which returns an iterator to a sorted copy of the sequence you pass it, saving you having to make the copy and sort it manually. - optimisations to list and tuple slicing, many dictionary methods, list appending/popping, and list comprehensions generally - a collections.deque object heavily optimised for adding and removing values at each end, useful for queue implementation if you somehow find that lists aren't up to the job - heapq algorithm reimplemented in C to provide a 10x optimisation; great for priority queue usage in pathfinding algorithms and the like - the profile module can now profile C extension functions - and a few more minor improvements.

Thanks for the info!!

To be honest I am not all that keen on function decorators - although I expect they will make some interesting metaprogramming tricks quite easy, or on the generator expression concept, although I will probably adapt to that quite quickly.

When I've looked at Ruby I've always thought that it is probably a step closer to Lisp in terms of flexibility and expressive power but it does look more complex in general. Python occupies a space a little closer to the user-friendly end of the spectrum, and these latest changes are probably the only way they can add in extra power without compromising the ease of use.

Regarding the generator expression syntax, C++ has largely superfluous parentheses too (eg. the expression in an if statement) so I doubt we'll take too long to adjust there.

Quote: Original post by Pxtl
My point is this: it is perfectly possible to make most of the features that Python currently has into modular extensions instead of interepreter-built-in stuff while maintaining legibility such that the current code-base remains intact. Instead, the Python developers insist on adding kludgy extensions that increase the complexity of the language.

But the whole point is that these things can't be done to Python without a language change. A generator expression isn't something a library can add on without the language being able to adapt to that, as it has implications for the parser at the very least. I'm not sure what other kludgy extensions you were thinking of.

Yeah, but your point has no purpose. Python is what it is. Either you can start again from the beginning, with a new language, or you can add things to it, improving the current language but possibly introducing a special case here and there. No point complaining about what it could have been if someone had made a different decision 15 years ago when it was created, because that's just parallel-universe thinking. Python can't be totally rewritten with a different syntax and grammer now because then it wouldn't be Python and Python programs wouldn't run on it.