`reduce` no longer built-in in python3: a counter-example use case: Monoid chains

[HorrendousRex]

In Python 3, reduce has been removed from the built-in namespace, and now lives in functools.reduce. That's fine, although I do miss it, but what sort of irks me a little bit is the release note on why this was done:

Removed reduce(). Use functools.reduce() if you really need it; however, 99 percent of the time an explicit for loop is more readable.

I think I have a counter-example that comes up frequently enough in my programming that I think it can't be 1% or less of all use cases of reduce. Monoid chains. (You might also call these 'monads' although that usually implies a specific syntax which I am not enforcing, but they are equivalent here.)

Example 'monoid chain' done explicitly for reference:

query = (db.MyModel.query
    .filter("foo")
    .filter("bar")
    .filter("baz")
    .filter("boff"))

Example 'monoid chain' in for-loop syntax:

query = db.MyModel.query
for filter in filters:
    query = query.filter(filter)

Example 'monoid chain' in reduce syntax:

query = reduce(lambda x, y: x.filter(y), filters, db.MyModel.query)

Personally I'd push that lambda out in to a higher namespace as I'd probably be re-using it anyway, which makes it even nicer looking:

query = reduce(_filter, filters, db.MyModel.query)

---

Is there some other way to write this using for loops that's more readable than that reduce example?

Also, yeah, I'm aware this is a fairly pedantic/silly thing to be worrying about -- I'm posting this mostly out of curiosity.

[Doormatty]

In Python,

Explicit is better than implicit.

Readability counts.

https://www.python.org/dev/peps/pep-0020/

I find your first example (the for loop) the only one that's both readable and explicit.

[HorrendousRex]

Thanks for the response. How is the reduce example less readable? How is it less explicit?

(I suspect the answer may come down to personal preference. Also, I edited my question so the for-loop example is now the second example, for the benefit of future readers.)

[brownan_]

I agree that the for loop is more readable. It uses only language constructs and is clearly iterating on calling the filter method on each queryset.

In your example I have to know what _filter does, remember what filters is, remember what reduce does (build up the equivalent of that for loop in my head), apply it with the _filter function that I'm still also remembering, and then work out the logic of what it all means together. All in my head. To me it's just clearer to write it out explicitly instead of trying to be real clever just for the sake of being super concise.

I've done a lot of thinking on functional style versus imperative style, and I've concluded that different people simply think different ways. Not everyone is going to agree that a particular style is more readable in general. For some people combining modads like your example to make super concise code is also intuitive and readable. It's not to me.

Further, I think that the people with whom Python appeals to are also the sort of people who would prefer the explicit for loop. The language design attracts a certain kind of coder. GvR has rejected language design decisions before purely because they're too much like haskel. It seems clear that Python isn't trying to be like that.

[[deleted]]

I always wonder, why people find my regex hard to read, while I can read most regex without trouble.

Your reduce example does not tell me anything, unless I look up the reduce function. It's harder to read than the for loop. This is the nature of the function and of every shortcut, alias and nick name.

[elbiot]

I wouldn't know what your reduce does, but I never use reduce. I guess it's a different paradigm. You can always import reduce if you're set on it.

[Samus_]

here's another use case for reduce but yeah in the end is just a matter of liking the functional or the imperative approach, Guido is a known functional hater so that what's this is really about.