First one is far far easier for me to understand for two reasons:
* The table-like structure of the conditions instead of nesting like the second one. The two-dimensional relationship makes it trivial to reason about - understanding it works at a higher level than the individual variables.
* The body of the conditional is entirely self-contained and can be understood separately from the conditional instead of having to understand them both at the same time.
The refactor they suggest at the end only works so simply because of my second reason here. It's kind of an improvement (self-contained logic that can be reused), but kind of not (now you have to look in two locations to actually understand what it's doing), but either way isn't really necessary if you read code at a higher level than token-by-token.
I found that the meaning of the first one was a lot easier, but there are a lot of assumptions about the called sub-functions... Mainly that they actually behave in a way that's consistent with their names. (I've gotten bitten by that a lot).
The second function is harder to to understand in the sense of meaning, but easier to understand in the sense of raw behavior. I can see more of the code that determines it's actual behavior, and can inspect and trust that the logic is appropriate.
One could argue that the same holds for the second example. Sure, the parameter is called `numbers` but who knows what it will contain at runtime. It could be full of vectors, matrices or sheep. _Some_ of the objects could have a custom definitions for __lt__ and __mod__ (custom overloads for the < and % operators in Python).
In that sense, if we accept that `<` and `%` have sensible definitions in the second example, it would only be fair to assume the same for the helper functions first example.
* The table-like structure of the conditions instead of nesting like the second one. The two-dimensional relationship makes it trivial to reason about - understanding it works at a higher level than the individual variables.
* The body of the conditional is entirely self-contained and can be understood separately from the conditional instead of having to understand them both at the same time.
The refactor they suggest at the end only works so simply because of my second reason here. It's kind of an improvement (self-contained logic that can be reused), but kind of not (now you have to look in two locations to actually understand what it's doing), but either way isn't really necessary if you read code at a higher level than token-by-token.