Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


There'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.


> It's tiring fighting against a community and a (benevolent) dictator that disagree with you.

That summarizes the problem I guess :D


If I remember correctly, "removing" these functions mostly just meant dumping them into the functools module rather than including them as a built in function.


Yeah 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.


They ultimately weren't removed. reduce was removed from the builtins, but it's still just one import away. From itertools import reduce.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: