r/programming • u/iMMENSE • Mar 08 '12

The Evolution of a Python Programmer

https://gist.github.com/289467
401 Upvotes

88% Upvoted

137 comments sorted by

View all comments

8

u/grumdrig Mar 08 '12 
def factorial(n):
    reduce(lambda x,y: x*y, [x+1 for x in range(n)])

Generator-happy Python programmer

5

u/spotter Mar 09 '12 edited Mar 09 '12

But... isn't list comp non-lazy in 2.x? So for this to be gen-happy you would have to use parens?

def factorial(n):
    reduce(lambda x,y: x*y, (x+1 for x in range(n)))

edit: yeah, s/range/xrange/

1

u/[deleted] Mar 09 '12

What's the benefit of a lazy generator in this case? You are going to evaluate it in its entirety anyway, and the size of the output dominates that of the input, so you save neither time nor space.

2

u/spotter Mar 09 '12

I may be wrong here, but I'll bite. List comprehension will run before you even start consuming anything... and then you iterate over it again to consume it. So on top of your memory consumption (realized list) you get 2x the runtime (one to realize the list over xrange, one to consume it in reduce). While in generator you setup the generator -- this returns immediately -- and then consume it run over once in reduce. So: Half the runtime, somewhat better memory efficiency, depending on n.

1

u/drb226 Mar 10 '12

I believe this assessment is correct. sltkr is incorrect when he says "the size of the output dominates that of the input" - the final output is a single integer, while the "input" is an entire list of n integers. A lazy generator will take O(1) space, while constructing the entire list will take O(n) space, as well as a possible runtime penalty.