Return to Answer

added 129 characters in body

edited Aug 29, 2018 at 18:44

edited Aug 29, 2018 at 18:44

Function design: check_if_condition_was_met(...) is an awkward name, partly because of the unusual use of past tense. But why make it so wordy? Couldn't you just call it verify(...)?

Furthermore, it would be customary to put the condition parameter first, and the row second. It would certainly read more naturally in English, especially after the function rename. Also, based on the observation that verify(condition) could be considered as a test, it's a general functional-programming principle that the condition parameter should be considered more tightly associated with the verification process and should therefore be put first.
Use all(...): To You want to express the idea that a function should return True if all of the conditions must be met, and False if any condition fails, use. You can do that using all() with a generator expression. It's a lot less cumbersome than your condition_met, for, continue, and break. The entire function can be simplified down to a single expression!
Naming: I think that "key" and "val" are not quite descriptive enough. I suggest the following renamings:

key → comparator
val → criteria
condition_key → key
condition_val → desired_val

Function design: check_if_condition_was_met(...) is an awkward name, partly because of the unusual use of past tense. But why make it so wordy? Couldn't you just call it verify(...)?

Furthermore, it would be customary to put the condition parameter first, and the row second. It would certainly read more naturally in English, especially after the function rename. Also, based on the observation that verify(condition) could be considered as a test, it's a general functional-programming principle that the condition parameter should be considered more tightly associated with the verification process and should therefore be put first.
Use all(...): To express the idea that a function should return True if all of the conditions must be met, and False if any condition fails, use all(). It's a lot less cumbersome than your condition_met, for, continue, and break. The entire function can be simplified down to a single expression!
Naming: I think that "key" and "val" are not quite descriptive enough. I suggest the following renamings:

key → comparator
val → criteria
condition_key → key
condition_val → desired_val

Function design: check_if_condition_was_met(...) is an awkward name, partly because of the unusual use of past tense. But why make it so wordy? Couldn't you just call it verify(...)?

Furthermore, it would be customary to put the condition parameter first, and the row second. It would certainly read more naturally in English, especially after the function rename. Also, based on the observation that verify(condition) could be considered as a test, it's a general functional-programming principle that the condition parameter should be considered more tightly associated with the verification process and should therefore be put first.
Use all(...): You want to express the idea that a function should return True if all of the conditions must be met, and False if any condition fails. You can do that using all() with a generator expression. It's a lot less cumbersome than your condition_met, for, continue, and break. The entire function can be simplified down to a single expression!
Naming: I think that "key" and "val" are not quite descriptive enough. I suggest the following renamings:

key → comparator
val → criteria
condition_key → key
condition_val → desired_val

answered Aug 29, 2018 at 18:37

answered Aug 29, 2018 at 18:37

Similar to @Peilonrayz, I would map each of the comparators to a function, but I'd go further.

Function design: check_if_condition_was_met(...) is an awkward name, partly because of the unusual use of past tense. But why make it so wordy? Couldn't you just call it verify(...)?

Furthermore, it would be customary to put the condition parameter first, and the row second. It would certainly read more naturally in English, especially after the function rename. Also, based on the observation that verify(condition) could be considered as a test, it's a general functional-programming principle that the condition parameter should be considered more tightly associated with the verification process and should therefore be put first.
Use all(...): To express the idea that a function should return True if all of the conditions must be met, and False if any condition fails, use all(). It's a lot less cumbersome than your condition_met, for, continue, and break. The entire function can be simplified down to a single expression!
Naming: I think that "key" and "val" are not quite descriptive enough. I suggest the following renamings:

key → comparator
val → criteria
condition_key → key
condition_val → desired_val

I'm also skeptical about some of the behaviour when given anomalous input:

Why are there int(...) casts with 'min' and 'max'? Is it for parsing strings as numbers? None of your example cases needs such parsing, though. Is it for truncating floats towards zero? Probably not, but it might have that unintended effect, if the thresholds or data are already numeric.
What happens if the row is missing a key that is specified in the condition? Maybe it's not a concern to you, but it might be more appropriate to have the function return False rather than raise a KeyError, as your code does?

Consider writing doctests to explain what the function does. This is a situation where examples are more expressive than words.

Suggested solution