Earlier quoted context omitted.
The equivalent python is: mss = lambda x: max(scan(lambda a,b: max(0,a+b),0,x)) assuming a definition "scan" (which is like "reduce", except it gives you all intermediate values), an example of which is: def scan(f,x0,x): r = [x0] for x1 in x: x0 = f(x0, x1) r.append(x0) return r Note that the K is idiomatic whereas the python is (arguably) not. Of course, it could be worse; the advantage is that, much like math, the…
Oh goodness... don't do scan like that. Way easier (and more efficient) to use a generator: def scan(f, iterator, initial=0): yield initial yield from scan(f, iterator, f(initial, next(iterator))) Even with python2, you could make a non-recursive version that'd be still shorter than your scan and faster. Alternatively, you could pair a coroutine with that reduce function.... But always be suspect of your code if you…
Second, it is ~10% faster, but that speed difference disappears completely if you eliminate the namespace lookup (that is, add e.g. "o = r.append" before the loop, and call o() instead of r.append() inside the loop). It potentially uses less memory - but not the way you did it (unless Python 3 gained TCO when I wasn't looking. Did it?) - your formulation does not load the call stack, but it does create len(iterator) generators that - until the innermost StopIteration - all need to live somewhere on the heap. recursive solutions without TCO are rarely good enough to replace iteration.
Even if you did it right, it's more efficient, but not significantly so timewise, and slightly easier to use iterators in general, yes. It is mostly space-efficient in general.
I think it is more idiomatic, though - and also Python2 compatible - to just replace references to 'r' with yield in my code, than using the recursive definition you gave above - which is more idiomatic in functional languages, but less in Python (and harder to debug in any language than the iterative version)