4 ms·

List comprehensions are more a substitute for map than anything else (which is generally discouraged in the ecosystem). For comparison: `map(lambda x: x * 2, ra

List comprehensions are more a substitute for map than anything else (which is generally discouraged in the ecosystem). For comparison: `map(lambda x: x * 2, range(10))` vs `[x * 2 for x in range(10)]`. However lambdas are mostly discouraged because they're often harder to read for anything non-trivial (and really you can't do much non-trivial with them since they are so dwarfed) and you can just define a function in the same block and pass the function reference in place of a lambda. I think the premise is more that it's clearer to pass a clearly named method describing the intent instead of a lambda describing the how.

KirinDave 8y ago
This is an assertion by a Supreme Dictator of the ecosystem. It's not actually backed by any metrics. It not indicated by any stuides. It's not borne out in any data brought to you by teachers. It's actually contradictory to previous findings. We can also see a migration away from list and object comprehensions in languages that support both them and lambdas (e.g., C#, Haskell). How the Python community has maintained it's opinion that everyone else is stupid and wrong while also suggesting that their tooling is impossible to understand is beyond me. It seems like a contradictory position.
- nerdwaller 8y ago
  That's true, though being pretty involved in the ecosystem (e.g. anecdote) I believe that people tend to agree with the general concepts (with exceptions). > it's opinion that everyone else is stupid and wrong I can't speak for the BDFL, but I don't believe this is the intent. It's not meant to say everyone else is wrong and Python is right, rather that Python prefers fewer ways to do things and certain complexities aren't worth it when there's a good way already in the language to do $feature. Complexity may not be in the python layer even, it could be maintenance in the underlying implementation (CPython, PyPy, Jython, ...)
- dorfsmay 8y ago
  In Python without type annotation, what do you find about a lambda that is easier than a named function?
  - KirinDave 8y ago
    The ability to move closures and to rely on simple lambda applications rather than ad hoc hierarchies or more complex annotations that map over the same decorator patterns anyways. That's the big irony. Python embraces some of the most complex, detail oriented aspects of function-first programming with decorators, but then throws away most of the payoff. It's like eating the peel of a banana and refusing to eat the interior.

KirinDave 8y ago

This is an assertion by a Supreme Dictator of the ecosystem. It's not actually backed by any metrics. It not indicated by any stuides. It's not borne out in any data brought to you by teachers. It's actually contradictory to previous findings. We can also see a migration away from list and object comprehensions in languages that support both them and lambdas (e.g., C#, Haskell). How the Python community has maintained it's opinion that everyone else is stupid and wrong while also suggesting that their tooling is impossible to understand is beyond me. It seems like a contradictory position.

nerdwaller 8y ago
That's true, though being pretty involved in the ecosystem (e.g. anecdote) I believe that people tend to agree with the general concepts (with exceptions). > it's opinion that everyone else is stupid and wrong I can't speak for the BDFL, but I don't believe this is the intent. It's not meant to say everyone else is wrong and Python is right, rather that Python prefers fewer ways to do things and certain complexities aren't worth it when there's a good way already in the language to do $feature. Complexity may not be in the python layer even, it could be maintenance in the underlying implementation (CPython, PyPy, Jython, ...)
dorfsmay 8y ago
In Python without type annotation, what do you find about a lambda that is easier than a named function?
- KirinDave 8y ago
  The ability to move closures and to rely on simple lambda applications rather than ad hoc hierarchies or more complex annotations that map over the same decorator patterns anyways. That's the big irony. Python embraces some of the most complex, detail oriented aspects of function-first programming with decorators, but then throws away most of the payoff. It's like eating the peel of a banana and refusing to eat the interior.