The fate of reduce() in Python 3000

Link

Guido van Rossum comments on the elimination of map(), filter(), reduce() and lambda from Python 3000:

About 12 years ago, Python aquired lambda, reduce(), filter() and map(), courtesy of (I believe) a Lisp hacker who missed them and submitted working patches. But, despite of the PR value, I think these features should be cut from Python 3000.

He believes map and filter are unnecessary because there are list comprehensions. But what about reduce ? It seems Guido doesn't believe in folds:

So now reduce(). This is actually the one I've always hated most, because, apart from a few examples involving + or *, almost every time I see a reduce() call with a non-trivial function argument, I need to grab pen and paper to diagram what's actually being fed into that function before I understand what the reduce() is supposed to do. So in my mind, the applicability of reduce() is pretty much limited to associative operators, and in all other cases it's better to write out the accumulation loop explicitly.

And then, with these functions gone, there is no use for lambdas, he argues.

I find it positive, in general, when designers eliminate features from a programming languages, if they are rarely used, but maybe he is being too harsh on reduce(); it may be my predilection for functional programming getting on the way, though.

via PLNews

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Rigor

But then what language does offer this sort of rigor?

Haskell is the "pure" FP language, though I wonder if you already know this and are asking a question that I don't quite understand. If you are looking for something that guarantees our software will never fail then you are looking for the impossible. Even programs that have been "proven" correct may have an error in the specification.

If you want even more rigor than Haskell provides, take a look here: A Comparison of Z, B, and VDM.