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

I'm still miffed about function decorators - they're developing disgustingly messy syntax for it and putting off implementation over arguments about whether such-and-such syntax is "greppable" or things like that. I'm coming to think that Python has become an overcomplicated and bloated system. I keep wishing they'd chosen Ruby's custom-blocking and custom-statement system so that their blocks and statements wouldn't be such a kludge.

Languages should not grow organically.

I don't agree either with the function decorator nor the generator expression syntaxes - too much overloading of the few bracket types we have - but *shrug*.

Now if it's bloat you want, look at Perl. Python is not there, yet.

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.

Yes, but the difference is that custom blocks don't have to be the domain of Lisp-esque over complexity.

What does it matter if the "for" statement is part of the standard library or is hard-coded? Python does indeed have better syntax and builtin names than Ruby. But the difference is because of bad design on Ruby's part.

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.

So instead of robust, sensible solutions, we get things like decorators and the Lambda syntax.

Plus, I just prefer languages that use := for assignment. = means equality, not assignment.

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.

My point is that the syntax has become chock-full of special cases instead of sensible underlying rules. This makes it both a) difficult to manually extend, and b) difficult to teach consistently. On the surface it seems readable, but as you learn more about the language it becomes confusing (wait, so I can't use statements in lambda blocks?).

Rather than designing the syntax to be robust from the ground-up, they add little patchwork fixes that just make it more clumsy.

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.

Well, the Python developers frequently break backwards compatibility on features, so yes, they could add new lexical features that would require the slight modification of old code to accomodate it. And its not like its just a bunch've developers adding ideas left-right-and-center: were that the case, I'd expect teh sort of slap-together development we see. However, Python has a strong central leadership.

My point is that the language has become obsessed with practicality above theory so far that it has crossed the line into becoming impractically practical. The problem is that the code is legible, but the exact logic that the interpreter follows is so inconsistent that its very difficult to really know what's going on.