[untothebreach]

There are also a few non-idiomatic practices he seems to favor. For example, he seems to advocate use of `filter`, `map`, `reduce` in a few places, which, in Python, are better expressed with list comprehensions, combined with builtins like `sorted`, `all`, `any`, `sum`, etc. Adding the `operator` module opens up even more functional constructs without ever touching `map`, `reduce`, or `filter`.

[pcote]

Using list comprehensions as a replacement for filter and map I can see. I don't really see where you're getting at as far as substitutes for 'reduce' are concerned. For me, the 'operator' module is a justification for using 'reduce', not a replacement for it.

[masklinn]

> I don't really see where you're getting at as far as substitutes for 'reduce' are concerned.

Reduce simply isn't used much in Python code, as a product of both culture and rather lacking lambdas. It's used so little (pretty much the only "usual use case" is covered by `sum`) it's been moved out of the builtins and to the functools module in Python 3 (whereas `map` and `filter` have remained)

[untothebreach]

Thank you, that was much more eloquently put than I could have provided. Indeed, `sum` was the one common use case I could think of, so I didn't bother including it as an example. I honestly can't say I miss `reduce` at all when writing python.

[masklinn]

> Indeed, `sum` was the one common use case I could think of

There are 4 other not-completely-uncommon cases in the builtins, implemented in a significantly more efficient manner for the latter 2 (ignoring Python v C): min, max, any and all. And map and filter technically but repeatedly concatenating lists together (in python) isn't the most useful way to peg your CPU.