4 ms·
> I’d say that using lambda expressions is acceptable only if your situation meets all four of these criteria: > 1. The operation you’re doing is trivial: the
by davemp 8y ago
> I’d say that using lambda expressions is acceptable only if your situation meets all four of these criteria:
> 1. The operation you’re doing is trivial: the function doesn’t deserve a name
Sure.
> 2. Having a lambda expression makes your code more understandable than the function names you can think of
This is just vague. Locally defining a function right where you need it makes code much more understandable to me more often than the wacky names people often come up with. Naming things is hard!
> 3. You’re pretty sure there’s not already a function that does what you’re looking for
So the reader of the code has to know what that built-in function does. How is that much different than expecting the reader to know what a lambda is?
> 4. Everyone on your team understands lambda expressions and you’ve all agreed to use them
Or just use them and have the members of your team better themselves by learning a useful language feature.
---
In my experience, names lie--functions don't. If a developer isn't going to spend the time to write a nice comment, they aren't going to use a comprehensible naming convention. In trivial cases where naming is easy, the lambda is also usually very easy to parse.
- kache_ 8y ago>4. Everyone on your team understands lambda expressions and you've all agreed to use them This only might be valid if people on the team weren't programmers, but rather researchers that had to use python. In that case, the code would have to be very easy to understand. But in that case, they should probably learn what a lambda function is. It's really not that hard
- ndpi 8y agoAlso, wouldn't the existence of a library function (#3) imply that what you're doing is either non-trivial or common enough that someone has already given the function a name? Seems like #1 is sufficient.
- eesmith 8y agoTo give an example based on the article, I find it cumbersome to use itemgetter. I could use the library function: import operator sort(values, key=operator.itemgetter(2)) but it seems decidedly trivial and common to use a lambda: sort(values, key=lambda x: x[2])
- tomnipotent 8y agoThe first returns a callable, the second a value.
- codebje 8y agoThe first returns a callable that's the value assigned to the key argument. The second is a callable that's the value assigned to the key argument. They're the same thing.
- dpwm 8y agoThe risk of identifier collisions with itemgetter seems really low. I've never had a problem with from operator import itemgetter sort(values, key=itemgetter(2)) The main problem is the effort of typing the import, but last time I checked itemgetter performed a bit better. To me it depends on what I'm writing. If it's a library where performance will matter then it's the itemgetter approach. If it's a script it will be the lambda.
- siddboots 8y agoI've noticed a pattern in among python developers where the faux pas of assigning a lambda is used to signify "I'm going to use this function in a vaguely functional programming manner". For example, by passing it into map, or filter, or sorted. For this reason, I don't really mind it. It's a sort of cue to the reader about the style of programming that will follow.
- BerislavLopac 8y agoI many of those cases people use lambda when a partial would be a better fit.
- jim_and_derrick 8y agoman... i totally agree these things can be abused. co-worker was rewriting a project and went a little bit wild but i found the code pretty readable (for an experienced coder). You can do some pretty sweet stuff using built in python methods. We had a combination of dict/zip/map/lambda that run a ton of processing code and built a pretty complicated JSON-like structure in 4 lines. I personally liked it, you can tell some thought was put into the code rather then blasting out first solution and using that in production