为什么python列表理解有时不受欢迎?

Opt*_*mus 8 python list-comprehension

我见过的许多开发人员建议最好的做法是使用简单的循环,如果条件而不是一行列表理解语句.

我总是发现它们非常强大,因为我可以将大量代码放在一行中,并且它可以节省很多变量.为什么它仍然被认为是一种不好的做法?

(它慢吗?)

Pet*_*rin 22

列表推导用于创建列表,例如:

squares = [item ** 2 for item in some_list]
Run Code Online (Sandbox Code Playgroud)

对于使用列表(或其他对象)的元素执行某些操作,for循环更好:

for item in some_list:
    print(item)
Run Code Online (Sandbox Code Playgroud)

通常不赞成使用对其副作用的理解,或者用于创建列表的for循环.


这里的一些其他答案主张将理解变为循环,一旦变得太长.我不认为这样的风格很好:append创建列表所需的调用仍然很难看.相反,重构为一个函数:

def polynomial(x):
    return x ** 4 + 7 * x ** 3 - 2 * x ** 2 + 3 * x - 4
result = [polynomial(x) for x in some_list]
Run Code Online (Sandbox Code Playgroud)

只有你关心速度 - 而且你已经完成了剖析! - 你应该保持长期,不可读的列表理解.

  • 它们是为各自的任务而设计的.列表推导具有表达式,该表达式成为列表的项目.for循环有一段代码.表达式有利于计算价值; 代码块对于对对象执行任意操作是有益的.此外,传统方式也是这样做的:可读性非常关乎按照别人期望的方式做事. (3认同)
  • 需要注意的一件有趣的事情是:在“多项式”示例中,使用函数的一个重要原因是*命名概念*:理解现在读作“评估所有项目的多项式”而不是“用所有项目做一些看起来复杂的事情”项目”。 (3认同)

Joe*_*ton 6

这不算坏.

但是,列表理解也是如此

  1. 有副作用,或
  2. 作为多行for循环更具可读性

一般都不赞成.

换句话说,可读性很重要.

作为第一个不好的例子的过度设计的例子:

x = range(10)
[x.append(5) for _ in xrange(5)]
Run Code Online (Sandbox Code Playgroud)

基本上,如果你没有存储结果,和/或它修改了其他一些对象,那么列表理解可能是一个坏主意.

作为第二个例子,看看几乎所有用python编写的代码高尔夫条目.一旦您的列表理解开始成为一目了然的可读性,请考虑使用for循环.

  • `y = [如果x> 5,则x在xylist中为x]`一点也不差!这正是列表推导的目的,并且它比明确的for循环更具可读性. (4认同)
  • @Optimus:那个是完全可读的,一般来说完全不是惯用语.但是有些片段建议当有人问"我如何在一个列表理解中完成<5个非常重要的任务"?不是.像深度嵌套的列表推导与70-char表达式以及对更具异国情调的`itertools`函数的多层调用之类的事情.根据经验,我会说它不应该这么长,你必须将它分成两行. (3认同)

Raf*_*ler 5

没有性能上的影响(即使有,我也不会担心;如果性能如此重要,那么您使用了错误的语言)。有些人不喜欢列表理解,因为它们对某些人来说有点过于简洁,这是个人喜好的问题。一般来说,我发现简单的列表推导比它们的循环/条件等价物更具可读性,但是当它们开始变长时(例如,您开始超过 80 个字符),它们可能会更好地替换为循环。