Lambda expressions are great in spots. The most common use is when you need a short function to pass as an argument to another function. However, list comprehensions remove the need for a lambda in a call to map. In the first example
odds = list(filter(filterFunc, nums))
could be replaced with
[num for num in nums if num % 2]
You probably want to avoid lambda when the function is long (like in your toGrade example), when the function is likely to be used elsewhere in your code or if creating a named function helps with documenting your intentions. Using your first example, defining the function isEven, or isLower in the second would tilt the scales against using lambda.
good point, the odds example is definitely overkill when a list comprehension is a possible solution. I think this also answers, the question of using lambda's for multi conditional solutions.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Lambda expressions are great in spots. The most common use is when you need a short function to pass as an argument to another function. However, list comprehensions remove the need for a lambda in a call to map. In the first example
could be replaced with
You probably want to avoid lambda when the function is long (like in your toGrade example), when the function is likely to be used elsewhere in your code or if creating a named function helps with documenting your intentions. Using your first example, defining the function
isEven, orisLowerin the second would tilt the scales against using lambda.good point, the odds example is definitely overkill when a list comprehension is a possible solution. I think this also answers, the question of using lambda's for multi conditional solutions.