Lazy list/range comprehensions

[bearophile]

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