Andrei: > Not labeling it as such hurts the quality of the conversation.
> one shouldn't make claims without being able to substantiate them. You are right, sorry. > A link to a document that illustrates that motivation would be great. > For all I know Python 3 also transformed print from a statement into a > function, but for very different reasons. One of the first times I've seen a rationale behind the removal of reduce() was here, page 4, a text by Guido van Rossum, the Python main designer: http://www.python.org/doc/essays/ppt/regrets/PythonRegrets.pdf > * reduce() nobody uses it, few understand it a for loop is clearer & (usually) faster < Later this was the answer, by Guido still: http://www.artima.com/forums/flat.jsp?forum=106&thread=211200 > Q. If you're killing reduce(), why are you keeping map() and filter()? A. I'm not killing reduce() because I hate functional programming; I'm killing it because almost all code using reduce() is less readable than the same thing written out using a for loop and an accumulator variable. On the other hand, map() and filter() are often useful and when used with a pre-existing function (e.g. a built-in) they are clearer than a list comprehension or generator expression. (Don't use these with a lambda though; then a list comprehension is clearer and faster.)< I have used reduce() only a 2 or 3 times in some years of Python usage. Most other times a sum() or product() was enough. A simple implementation of product() using reduce(): >>> import operator >>> product = lambda seq: reduce(operator.mul, seq) >>> product(xrange(1, 10)) 362880 > Yeah, sum() is probably popular enough to deserve a special case. Good :-) Bye and thank you, bearophile
