3 ms·

I feel like list comprehensions have always been emphasized as an important part of writing idiomatic Python. And as Python added more constructs in that vein (

I feel like list comprehensions have always been emphasized as an important part of writing idiomatic Python. And as Python added more constructs in that vein (generator expressions, dict and set comprehensions) the tutorials people used didn't really keep up. In the same way, map and filter were often covered, but not always with an explanation of the style of programming they supported, or why that style could be useful. I do remember the original Dive Into Python did a good job of this, and of encouraging people to explore a more functional style, but I don't recall many other resources, at least from the (2004-ish) era when I was first learning Python, doing that. As a result I have to be a bit careful these days; I still use Python's more functional constructs regularly, but I've learned to go easy on them when collaborating with others, since I know a lot of people who learn Python now are using materials that mostly only touch on list comprehensions.

repsilat 9y ago
The "real functional" map/reduce/filter functions tend to be discouraged by programmers and linters too. It is becoming (has become?) an established part of the culture -- "Lambda in a `map`? Use a list comprehension instead." I guess it's a "sheep as a lamb" thing -- "The 'functional way' is either points-free or pointless." Maybe it's better in Rust because the method-style `x.filter().map().reduce()` lets you read left-to-right, and the "global function" `reduce(map(filter(x)))` has to be read inside-out. If there is a good reason to do Python's global function way, maybe D's UFCS can bring them the best of both worlds.
- ubernostrum 9y ago
  It is becoming (has become?) an established part of the culture -- "Lambda in a `map`? Use a list comprehension instead." Which is annoying, because there are times when using map or filter is cleaner; for example, if you're doing pipeline-y stuff, using the function-based approach is much easier to read and reason about than doing a bunch of nested comprehensions. I also tend to think people don't use itertools enough. But it catches people by surprise enough that several of my messing-with-interviewers canned solutions to common problems make heavy use of itertools (including a FizzBuzz which contains no 'for' or 'if' statements).

repsilat 9y ago

The "real functional" map/reduce/filter functions tend to be discouraged by programmers and linters too. It is becoming (has become?) an established part of the culture -- "Lambda in a `map`? Use a list comprehension instead." I guess it's a "sheep as a lamb" thing -- "The 'functional way' is either points-free or pointless." Maybe it's better in Rust because the method-style `x.filter().map().reduce()` lets you read left-to-right, and the "global function" `reduce(map(filter(x)))` has to be read inside-out. If there is a good reason to do Python's global function way, maybe D's UFCS can bring them the best of both worlds.

ubernostrum 9y ago
It is becoming (has become?) an established part of the culture -- "Lambda in a `map`? Use a list comprehension instead." Which is annoying, because there are times when using map or filter is cleaner; for example, if you're doing pipeline-y stuff, using the function-based approach is much easier to read and reason about than doing a bunch of nested comprehensions. I also tend to think people don't use itertools enough. But it catches people by surprise enough that several of my messing-with-interviewers canned solutions to common problems make heavy use of itertools (including a FizzBuzz which contains no 'for' or 'if' statements).