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.

FP is math?

I'm just a beginner starting a cs grad program, but as I understand it, FP was the beginning of the grand attempt to make a program conform to mathematical rigor. If that is the Holy Grail, then Python is definitely a Monty Pythonesque attempt to find this Holy Grail. But then what language does offer this sort of rigor?

I recall in another life as a geography student learning about digital mapping and satellite remote sensing. There were always huge piles of data to produce a raster image--and the only intelligent thing you could do with it is compress it. The vector method seemed to address this huge redundancy somewhat, but that also was based on piles of data. Then we heard about fractal geometry, where you could literally define a coastline as 1.23425247767448955, i.e. a number describing where the line was relative to a 2-dimensional field (that is, 1.2343... is not a 1-dim point, nor a 2-dim plane, but something in between). Where that went I don't know.

My point is that a purely mathematical way of mapping and satellite imagery would be to have a mathematical formula that would literally crank out the map or image. It might be way too Nietzschian to say there is a mathematical way to derive-prove that a place on an x,y grid would be name "Cheshireton". But you get the point. This seems to be what they're after with Fortress, if I'm not totally reading it wrong.

I've read FP people make very bold statements, such as FP is the only way forward. I take it they mean the only way to get the math rigor, the reliability--and not just some way to do a (new) sorting algorithm better or faster. A system based on proofs should be capable of being built to the sky--and not have it topple like a tower of Babel because impure handwaving or "anecdotal programming paradigms" weakened the structure. At least that's the theory as I understand it. Corrections welcome.

One of the great burrs under my saddle is what Ted K (Unabomber), a mathematician, said about software, how it runs somewhere but no one knows much about it. It handles something critical, but for all intents and purposes, maybe not out of-, but, say extra-control. If software was like math, any competant "math weenie" should be able to grok it, especially it's probablistic dimensions. This would quiet poor Ted's and my mind considerably more than the old, retired COBOL pro who had a look-see for $200/hr.

But having some FP in Python a start, right?, in the search for this Holy Grail.