紧凑的可读性差？ [复制]答案

【问题标题】：Being compact has bad readability? [duplicate]紧凑的可读性差？ [复制]
【发布时间】：2019-04-05 21:50:15
【问题描述】：

你如何看待Python中的两段代码sn-ps？

for a in aa:
    if a in nb:
        intsct.append(a)
        nb.remove(a)

如果将sn-p over的代码改写如下呢？

[intsct.append(a) or nb.remove(a) for a in aa if a in nb]

虽然它们都给了我相同的结果，但就 Python 的代码实践而言，哪一个更好？如果强调紧凑，我可以选择第二个吗？

【问题讨论】：

两者都未能通过关键测试：描述性变量名称。
一般来说，列表推导被认为比循环更“Pythonic”。（“平面优于嵌套”是“Python 之禅”的一部分。）但我不清楚这两段代码是否是同一件事。为什么理解中出现or 运算符？而且（在我看来）使用列表推导来简单地对列表的每个元素进行操作是非常奇怪的，而不是从原始列表中创建一个新列表。
投票结束主要基于意见。但在我看来，第二个代码掩盖了意图并无缘无故地生成了None 的列表。假设它有效，这不是对列表理解的适当使用。几乎可以肯定有比这两种方法更好的方法（可能使用set）；如果你posted your original problem 会更清楚。
列表理解还能运行吗？我从没见过or在开头这样使用。
@RobinZigmond：当目标是从现有的可迭代对象中生成全新的list 且没有副作用时，列表推导式是 Pythonic。如果您将它们用于副作用，或者忽略生成的list，不，完全不是 Pythonic。

【解决方案1】：

我不喜欢第二个，因为您实际上并没有使用这些结果：您构建一个列表纯粹是为了它的副作用，然后把它扔掉（这也是低效的；想象一下 aa 有一个亿项）。这还取决于知道list.append 返回None，以便or 子句导致list.remove 始终被调用。

当您可以找到一种表达意图的表达方式时，紧凑性就很棒。我认为这只是为了简洁而简洁，实际上并没有表达原始代码的目标。换句话说，如果你是我的同事，而我试图弄清楚为什么凌晨 2 点就坏了，我会诅咒你的名字。

【讨论】：