一般过滤器稍快，如果使用内置函数。

在您的情况下，我希望列表理解稍微快一些

我觉得第二种方法更容易读懂。它确切地告诉你目的是什么:过滤列表。 注意:不要使用list作为变量名

尽管过滤器可能是“更快的方式”，但“Python方式”是不关心这些事情，除非性能绝对关键(在这种情况下，您不会使用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中有点像宗教问题。尽管Guido考虑从Python 3中删除map、filter和reduce，但还是有足够的反对意见，最终只有reduce从内置迁移到functools.reduce。

就我个人而言，我发现列表推导式更容易阅读。从表达式[i for i in list if i.attribute == value]中发生的事情更加明确，因为所有的行为都在表面上，而不是在过滤器函数内部。

我不会太担心这两种方法之间的性能差异，因为它是微不足道的。我只会优化它，如果它被证明是你的应用程序的瓶颈，这是不太可能的。

此外，由于BDFL希望从语言中删除过滤器，那么肯定会自动使列表理解更python化;-)

一个重要的区别是，列表推导式将返回一个列表，而过滤器返回一个过滤器，你不能像操作列表一样操作它(即:在它上调用len，它不能与过滤器的返回一起工作)。

我自己的自学也让我遇到了类似的问题。

也就是说，如果有一种方法可以从过滤器获得结果列表，有点像在。net中执行lst时所做的那样。Where(i => i.something()). tolist()，我很想知道它。

编辑:这是Python 3的情况，而不是Python 2(见评论中的讨论)。

由于任何速度差异都必然是微乎其微的，因此使用过滤器还是列表推导式都取决于个人喜好。一般来说，我倾向于使用推导式(这似乎与这里的大多数其他答案一致)，但有一种情况下，我更喜欢过滤器。

一个非常常见的用例是根据谓词P(X)提取某个可迭代对象X的值:

[x for x in X if P(x)]

但有时你想先对值应用一些函数:

[f(x) for x in X if P(f(x))]

作为一个具体的例子，请考虑

primes_cubed = [x*x*x for x in range(1000) if prime(x)]

我认为这看起来比使用滤镜要好一点。但是现在想想

prime_cubes = [x*x*x for x in range(1000) if prime(x*x*x)]

在本例中，我们希望根据后计算值进行过滤。除了计算立方体两次的问题(想象一个更昂贵的计算)，还有编写表达式两次的问题，这违反了DRY美学。在这种情况下，我会使用

prime_cubes = filter(prime, [x*x*x for x in range(1000)])

过滤器就是这样。它过滤掉列表中的元素。你可以看到定义中提到了同样的内容(在我之前提到的官方文档链接中)。然而，列表理解是在对前一个列表上的内容进行操作后产生一个新的列表。(过滤器和列表推导式都创建新列表，而不执行替换旧列表的操作。这里的新列表类似于具有全新数据类型的列表。比如将整数转换为字符串，等等)

在您的示例中，根据定义，使用过滤器比使用列表理解更好。但是，如果您希望，例如列表元素中的other_attribute，在您的示例中是作为一个新列表检索，那么您可以使用列表推导式。

return [item.other_attribute for item in my_list if item.attribute==value]

这就是我对筛选器和列表理解的记忆。删除列表中的一些东西，并保持其他元素完整，使用过滤器。在元素上使用一些自己的逻辑，并创建一个适合某些目的的稀释列表，使用列表理解。

当我需要在列表理解之后过滤一些东西时，我使用了一小段。只是过滤器、lambda和列表的组合(或者称为猫的忠诚度和狗的清洁度)。

在这种情况下，我正在读取一个文件，剥离空行，注释掉行，以及在一行的注释之后的任何内容:

# Throw out blank lines and comments
with open('file.txt', 'r') as lines:        
    # From the inside out:
    #    [s.partition('#')[0].strip() for s in lines]... Throws out comments
    #   filter(lambda x: x!= '', [s.part... Filters out blank lines
    #  y for y in filter... Converts filter object to list
    file_contents = [y for y in filter(lambda x: x != '', [s.partition('#')[0].strip() for s in lines])]

我想我只是在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()的输出以及原始列表。

我花了一些时间来熟悉高阶函数过滤器和映射。所以我习惯了他们，我实际上喜欢过滤器，因为它是明确的，它通过保持任何真实的过滤，我觉得很酷，我知道一些函数编程术语。

然后我读了这篇文章(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

除了公认的答案之外，还有一种极端情况，即您应该使用过滤器而不是列表推导式。如果列表是不可哈希的，则不能使用列表推导式直接处理它。一个真实的例子是使用pyodbc从数据库读取结果。游标的fetchAll()结果是一个不可哈希的列表。在这种情况下，要直接对返回的结果进行操作，应该使用filter:

cursor.execute("SELECT * FROM TABLE1;")
data_from_db = cursor.fetchall()
processed_data = filter(lambda s: 'abc' in s.field1 or s.StartTime >= start_date_time, data_from_db) 

如果你在这里使用列表理解，你会得到错误:

TypeError:不可哈希类型:list

奇怪的是，在Python 3上，我看到过滤器执行得比列表推导更快。

我一直认为列表推导式的性能会更好。 喜欢的东西: [name为brand_names_db中的name，如果name不是None] 生成的字节码稍好一些。

>>> def f1(seq):
...     return list(filter(None, seq))
>>> def f2(seq):
...     return [i for i in seq if i is not None]
>>> disassemble(f1.__code__)
2         0 LOAD_GLOBAL              0 (list)
          2 LOAD_GLOBAL              1 (filter)
          4 LOAD_CONST               0 (None)
          6 LOAD_FAST                0 (seq)
          8 CALL_FUNCTION            2
         10 CALL_FUNCTION            1
         12 RETURN_VALUE
>>> disassemble(f2.__code__)
2           0 LOAD_CONST               1 (<code object <listcomp> at 0x10cfcaa50, file "<stdin>", line 2>)
          2 LOAD_CONST               2 ('f2.<locals>.<listcomp>')
          4 MAKE_FUNCTION            0
          6 LOAD_FAST                0 (seq)
          8 GET_ITER
         10 CALL_FUNCTION            1
         12 RETURN_VALUE

但它们实际上更慢:

   >>> timeit(stmt="f1(range(1000))", setup="from __main__ import f1,f2")
   21.177661532000116
   >>> timeit(stmt="f2(range(1000))", setup="from __main__ import f1,f2")
   42.233950221000214

总结其他答案

通过查看答案，我们已经看到了大量的反反复复，是否列表理解或过滤可能更快，或者关心这样的问题是否重要或python。最后，答案和大多数时候一样:视情况而定。

我只是在优化代码时偶然发现了这个问题，这个问题(尽管与in表达式结合在一起，而不是==)非常相关- filter + lambda表达式占用了我三分之一的计算时间(几分钟)。

我的情况

在我的例子中，列表理解要快得多(速度的两倍)。但我怀疑，根据过滤器表达式以及使用的Python解释器，这有很大的不同。

自己测试一下

下面是一个简单的代码片段，应该很容易适应。如果你对它进行剖析(大多数ide都可以很容易地做到这一点)，你就可以很容易地为你的特定情况决定哪个是更好的选择:

whitelist = set(range(0, 100000000, 27))

input_list = list(range(0, 100000000))

proximal_list = list(filter(
        lambda x: x in whitelist,
        input_list
    ))

proximal_list2 = [x for x in input_list if x in whitelist]

print(len(proximal_list))
print(len(proximal_list2))

如果您没有一个IDE可以让您轻松地进行概要分析，那么可以试试这个(从我的代码库中提取，因此稍微复杂一点)。这段代码片段将为您创建一个配置文件，您可以轻松地使用例如snakeviz可视化:

import cProfile
from time import time


class BlockProfile:
    def __init__(self, profile_path):
        self.profile_path = profile_path
        self.profiler = None
        self.start_time = None

    def __enter__(self):
        self.profiler = cProfile.Profile()
        self.start_time = time()
        self.profiler.enable()

    def __exit__(self, *args):
        self.profiler.disable()
        exec_time = int((time() - self.start_time) * 1000)
        self.profiler.dump_stats(self.profile_path)


whitelist = set(range(0, 100000000, 27))
input_list = list(range(0, 100000000))

with BlockProfile("/path/to/create/profile/in/profile.pstat"):
    proximal_list = list(filter(
            lambda x: x in whitelist,
            input_list
        ))

    proximal_list2 = [x for x in input_list if x in whitelist]

print(len(proximal_list))
print(len(proximal_list2))

你的问题既简单又有趣。它只是显示了python作为一种编程语言是多么的灵活。人们可以使用任何逻辑，根据自己的才能和理解来编写程序。只要我们得到答案就好。

在您的情况下，这只是一个简单的过滤方法，可以由两者完成，但我更喜欢第一个my_list = [x for x in my_list if x.attribute == value]，因为它看起来简单，不需要任何特殊的语法。任何人都可以理解这个命令，并在需要时进行更改。 (虽然第二种方法也很简单，但对于初级程序员来说，它仍然比第一种方法更复杂)

就性能而言，这要视情况而定。

filter不返回一个列表而是一个迭代器，如果你需要列表“立即”过滤和列表转换，它比非常大的列表(>1M)的列表理解要慢40%左右。到100K的元素几乎没有区别，从600K开始就开始有区别了。

如果不转换为列表，筛选实际上是即时的。

更多信息请访问:https://blog.finxter.com/python-lists-filter-vs-list-comprehension-which-is-faster/

我会得出结论:使用列表理解而不是过滤器，因为它

更具可读性 更多的神谕的 更快(对于Python 3.11，参见附带的基准测试，也参见)

请记住，filter返回一个迭代器，而不是一个列表。

python3 -m timeit '[x for x in range(10000000) if x % 2 == 0]'            

1个循环，5个最佳:每循环270毫秒

python3 -m timeit 'list(filter(lambda x: x % 2 == 0, range(10000000)))'

1个循环，最好的5:432毫秒每循环