3 ms·
Just readability for me. It's easier to read if the function is defined where it's used rather than before. apply(lst, () => { ... ... }) instea
by Frotag 4y ago
Just readability for me. It's easier to read if the function is defined where it's used rather than before.
apply(lst, () => {
...
...
})
instead of
def naming_is_hard():
...
...
apply(lst, naming_is_hard)
- zasdffaa 4y agoAgreed with @richiebful1, multiliners are better as standlone funcs, and I'd say (personal opinion) that they'd be better here. I like functional a lot but I don't lambda up unless it's more or less a one-liner or a kind of control structure, where they can get large but that's the point. I've had to deal with too much shit code where lambdas within lambdas are considered hot. Added bonus, the names are useful (naming is hard because if you do it right you are adding valuable information). I'm sure there are cases where doing it your way are better, but I can't think of them.
- rjmill 4y agoIf `apply` is your own code, you could refactor it to @apply(lst) def naming_is_hard(): ... I came to python after working in JS fulltime for years, and used to complain about the exact same thing. After I started using decorators, I stopped complaining about the single-line lambdas. For any non-python devs looking at my example, it's equivalent to def naming_is_hard(): ... naming_is_hard = apply(lst)(naming_is_hard) It's a nice way to pass functions into other functions, much like how you'd do with a lambda. edit: s/list/lst/g because autocorrect "fixed" the variable name.