该楼层疑似违规已被系统折叠 隐藏此楼查看此楼
估计你指的是 map
map, filter, reduce(某些语言里叫 fold,还可能分左右)属于 functional programming 的概念,好些 functional 语言里没有循环,类似的运算就是通过这些函数和递归实现
而 for, while 等显式循环来自 imperative programming
因为 python 既支持 functional 也支持 imperative,所以你看到同时有两个类似功能的东西,其实当初出现的目的并不是一定要那个替代那个【1】
而且因为 python 的 function 是 first-class 的,所以即使没有 map, filter, reduce 也可以自己实现
那么有 map 和显式循环比起来有什么优势呢
要知道大部分编程语言的发展过程,都以增加越来越多的抽象手段为趋势
如 机器码 -> 汇编 -> 高级语言 -> DSL
如 imperative -> procedual -> structured -> OO
(这里的箭头方向不代表高低之分)
支持抽象的方式越多,则处理起问题来就越灵活,越能合理划分,减少重复代码,减低出错几率
从概念上看
map, filter, reduce 这类高阶函数提供了更高一层的抽象,就是这些函数封装了循环,将循环和操作抽象出来
和 imperative 的循环比起来,在概念上,这些函数更清晰【2】,因为这些函数凸显了最关键的地方,就是遍历时做对每个元素做什么操作,属于 what,并不关心怎么(how)循环的
而 imperative 的循环,以 C 语言风格的 for (;;) 为例,则除了说明 what 之外,还需要写 how
不过在 python 的 for 实际上是 foreach,概念上比 C 的 for 高级点,这里 map 的概念清晰这个优势没有这么显著
从效率来看
根据我的经验,而且没记错的话
在 CPython 2.x 中,由于 map 的循环和循环变量等操作都是 C 的速度,所以一般情况下,map 的操作函数只要是内建函数(或者以 C 速度运行,总时间短的),通常就 map 比 comprehension 快,而 comprehension 又比 for 快
当操作函数是 python 源码级别速度的,特别是运行速度不快的,则 map 的优势不再明显
在 CPython 3 中,由于 map 变成返回 generator,再加上 comprehension 的优化做得更好,一般情况下 comprehension 比 map 快,某些极端情况下甚至 map 比普通 for loop 还慢
具体的你可以用 timeit 测试
而从所谓是否 pythonic 的角度看
一般看法是 map < for .. in < comprehension
但我觉得选用哪个大部分看写的人的风格和思维方式,比如倾向 functional 的人用 map, filter, reduce 可能会更舒服
【1】BDFL 确实想用显式循环和 comprehension 完全取代 map/filter/reduce,但是社区阻力挺大,最后只做到了在 python3 将 reduce 塞了进 functools,对于这个结果,个人感觉还是很庆幸,当然,python 3 的 map 等改成返回 generator,效率有所减低,这些函数从某个角度上讲实用性减低(从另外一个角度则有略为增加),BDFL 想除去 functional programming 的目的可以说迈进了一步,对于这个,个人又觉得有点那个
【2】如果读者没有 functional programming 的经验,则看起来更不直观,但这和数学公式一样,没学会前当然都是不直观的,并非这些函数的问题