3 ms·
I know you all know this, but I feel like it bears mentioning that nobody is forcing you to use list comprehensions whether map/filter stay in Python's built-in
by ramen 17y ago
I know you all know this, but I feel like it bears mentioning that nobody is forcing you to use list comprehensions whether map/filter stay in Python's built-ins or not. They can be defined in around 3-4 lines of code each. Lisp aficionados, already accustomed to the bottom-up style of programming, ought to have no problem writing functions like these as necessary.
- riobard 17y agoYeah I know. Maybe "force" is not the right word ... probably "discourage"? Actually only one line of code is enough for each of map/filter: def map(fn, seq): return [fn(each) for each in seq] def filter(cond: seq): return [each for each in seq if cond(each)] But seriously, what do you really gain by removing these two? Isn't that too ideological? I don't really see how un-Pythonic it would be to use map/filter instead of list comprehensions. The problem is BDFL's attitude seems to drive many FP-ers away, like the guy in the original post.
- kingkilr 17y agoThey ultimately weren't removed. reduce was removed from the builtins, but it's still just one import away. From itertools import reduce.
- ricree 17y agoIf I remember correctly, "removing" these functions mostly just meant dumping them into the functools module rather than including them as a built in function.
- holygoat 17y agoThere's a difference between things being possible and being encouraged. De-emphasizing functional operations makes it more likely for libraries to work in a non-functional style, for tutorials to do so, etc. It's tiring fighting against a community and a (benevolent) dictator that disagree with you.
- riobard 17y ago> It's tiring fighting against a community and a (benevolent) dictator that disagree with you. That summarizes the problem I guess :D