4 ms·

no it's not -- every other languages other than JS/TS has multiline lambdas... Java 8+, Kotlin, Rust, Scala, C#, ... seems you're confused between "limitation"

no it's not -- every other languages other than JS/TS has multiline lambdas... Java 8+, Kotlin, Rust, Scala, C#, ... seems you're confused between "limitation" and "feature"... it's a limitation due to python's "no-braces/indentations-only" policy -- can't think of a way to mark where a lambda starts and ends clearly and cleanly with indentation-only...

urxvtcd 6y ago
I mean, yeah, maybe that's the reason, I don't know. Still, I see no reason why you'd split features and limitations into two distinct sets. In Rust it's difficult to mess with memory: it's a limitation but also a feature. In Haskell you cannot mutate, a limitation if there ever was one, but also a feature.
- high_density 6y ago
  woah another rustacean? hi there! for rust, it counts as a 'feature' because it provides safety guarantee, and they're opt-in (can use unsafe) as for haskell, that immutability also provides guarantee of 'referential-transparency', which the users/libraries can use to their advantange. But in python's case, you have to define the multi-line function *outside* the chaining, and 'forcing to name things' isn't always good (especially for constantly-changing code) def hideEmail(user): return { ...user, email: user.hideEmail? '': user.email, } users.map(hideEmail) // later: def hideEmailAndPhone(user): return { ...user, email: user.hideEmail? '': user.email, phoneNo: ... // same stuff } users.map(hideEmailAndPhone) --- As for JS/TS, you can have 'named-callback-fn': users.map(function hidePrivateFields(user) { ... }) and it's not difficult to come up with 'named-lambda-fn' standard users.map(hidePrivateFields(user) => { ... })
joshuamorton 6y ago
Disallowing multiline-lambdas was an intentional choice by the creators to prevent overly-functional code. For the same reasons that map/filter/reduce aren't in the global namespace anymore. Python prefers different tools (comprehensions) to accomplish most of the same goals.

urxvtcd 6y ago

I mean, yeah, maybe that's the reason, I don't know. Still, I see no reason why you'd split features and limitations into two distinct sets. In Rust it's difficult to mess with memory: it's a limitation but also a feature. In Haskell you cannot mutate, a limitation if there ever was one, but also a feature.

high_density 6y ago
woah another rustacean? hi there! for rust, it counts as a 'feature' because it provides safety guarantee, and they're opt-in (can use unsafe) as for haskell, that immutability also provides guarantee of 'referential-transparency', which the users/libraries can use to their advantange. But in python's case, you have to define the multi-line function *outside* the chaining, and 'forcing to name things' isn't always good (especially for constantly-changing code) def hideEmail(user): return { ...user, email: user.hideEmail? '': user.email, } users.map(hideEmail) // later: def hideEmailAndPhone(user): return { ...user, email: user.hideEmail? '': user.email, phoneNo: ... // same stuff } users.map(hideEmailAndPhone) --- As for JS/TS, you can have 'named-callback-fn': users.map(function hidePrivateFields(user) { ... }) and it's not difficult to come up with 'named-lambda-fn' standard users.map(hidePrivateFields(user) => { ... })

joshuamorton 6y ago

Disallowing multiline-lambdas was an intentional choice by the creators to prevent overly-functional code. For the same reasons that map/filter/reduce aren't in the global namespace anymore. Python prefers different tools (comprehensions) to accomplish most of the same goals.