我有一个列表,我想通过项目的属性进行筛选。
以下哪个是首选(可读性,性能,其他原因)?
xs = [x for x in xs if x.attribute == value]
xs = filter(lambda x: x.attribute == value, xs)
我有一个列表,我想通过项目的属性进行筛选。
以下哪个是首选(可读性,性能,其他原因)?
xs = [x for x in xs if x.attribute == value]
xs = filter(lambda x: x.attribute == value, xs)
当前回答
这在Python中有点像宗教问题。尽管Guido考虑从Python 3中删除map、filter和reduce,但还是有足够的反对意见,最终只有reduce从内置迁移到functools.reduce。
就我个人而言,我发现列表推导式更容易阅读。从表达式[i for i in list if i.attribute == value]中发生的事情更加明确,因为所有的行为都在表面上,而不是在过滤器函数内部。
我不会太担心这两种方法之间的性能差异,因为它是微不足道的。我只会优化它,如果它被证明是你的应用程序的瓶颈,这是不太可能的。
此外,由于BDFL希望从语言中删除过滤器,那么肯定会自动使列表理解更python化;-)
其他回答
我花了一些时间来熟悉高阶函数过滤器和映射。所以我习惯了他们,我实际上喜欢过滤器,因为它是明确的,它通过保持任何真实的过滤,我觉得很酷,我知道一些函数编程术语。
然后我读了这篇文章(Fluent Python Book):
映射和筛选函数仍然是内置的 在Python 3中,但是自从引入了列表推导式和generator ex‐ 压力没有那么重要。listcomp或genexp完成map和的工作 过滤器组合,但更可读。
现在我想,如果您可以使用已经广泛传播的习语(如列表推导)来实现它,那么为什么还要使用过滤器/映射的概念呢?此外,映射和过滤器是一种函数。在这种情况下,我更喜欢使用匿名函数lambdas。
最后,为了进行测试,我对两种方法(map和listComp)都进行了计时,我没有看到任何相关的速度差异,可以证明这是合理的。
from timeit import Timer
timeMap = Timer(lambda: list(map(lambda x: x*x, range(10**7))))
print(timeMap.timeit(number=100))
timeListComp = Timer(lambda:[(lambda x: x*x) for x in range(10**7)])
print(timeListComp.timeit(number=100))
#Map: 166.95695265199174
#List Comprehension 177.97208347299602
我想我只是在python 3中添加,filter()实际上是一个迭代器对象,所以你必须将你的filter方法调用传递给list(),以构建过滤后的列表。所以在python 2中:
lst_a = range(25) #arbitrary list
lst_b = [num for num in lst_a if num % 2 == 0]
lst_c = filter(lambda num: num % 2 == 0, lst_a)
列表b和c具有相同的值,并且在filter()等效的时间内完成[x for x in y if z]。然而,在3中,相同的代码将使列表c包含一个筛选器对象,而不是一个筛选过的列表。要在3中产生相同的值:
lst_a = range(25) #arbitrary list
lst_b = [num for num in lst_a if num % 2 == 0]
lst_c = list(filter(lambda num: num %2 == 0, lst_a))
问题是list()接受一个可迭代对象作为参数,并从该参数创建一个新列表。结果是,在python 3中以这种方式使用filter所花费的时间是[x for x in y if z]方法的两倍,因为你必须遍历filter()的输出以及原始列表。
这在Python中有点像宗教问题。尽管Guido考虑从Python 3中删除map、filter和reduce,但还是有足够的反对意见,最终只有reduce从内置迁移到functools.reduce。
就我个人而言,我发现列表推导式更容易阅读。从表达式[i for i in list if i.attribute == value]中发生的事情更加明确,因为所有的行为都在表面上,而不是在过滤器函数内部。
我不会太担心这两种方法之间的性能差异,因为它是微不足道的。我只会优化它,如果它被证明是你的应用程序的瓶颈,这是不太可能的。
此外,由于BDFL希望从语言中删除过滤器,那么肯定会自动使列表理解更python化;-)
奇怪的是,不同的人的美相差如此之大。我发现列表理解比filter+lambda清晰得多,但使用您认为更容易的。
有两件事可能会减慢你使用滤镜的速度。
首先是函数调用开销:一旦使用Python函数(无论是由def还是lambda创建的),过滤器很可能会比列表理解慢。几乎可以肯定,这并不重要,在对代码进行计时并发现它是一个瓶颈之前,您不应该过多地考虑性能,但区别是存在的。
可能应用的另一个开销是lambda被强制访问一个有作用域的变量(值)。这比在python2中访问局部变量要慢。X,列表推导式只访问局部变量。如果你使用的是Python 3。X,列表综合在一个单独的函数中运行,因此它也将通过闭包访问值,这种差异将不适用。
另一个可以考虑的选项是使用生成器而不是列表推导式:
def filterbyvalue(seq, value):
for el in seq:
if el.attribute==value: yield el
然后在你的主代码中(这是可读性真正重要的地方),你用一个有意义的函数名替换了列表理解和过滤器。
尽管过滤器可能是“更快的方式”,但“Python方式”是不关心这些事情,除非性能绝对关键(在这种情况下,您不会使用Python!)。