简化列表理解

Question

在很多情况下，我希望python语法用于短路列表理解或生成器表达式。在

下面是一个简单的列表理解，以及python中的for循环的等价物：

my_list = [1, 2, 3, 'potato', 4, 5]
[x for x in my_list if x != 'potato']

result = []
for element in my_list:
    if element != 'potato':
        result.append(element)

语言中没有对短路的理解的支持。建议的语法，以及python中的等效循环：

^{pr2}$

它应该可以处理任意的iterable，包括无限序列，并且可以扩展到生成器表达式语法。我知道list(itertools.takewhile(lambda x: x != 'potato'), my_list)是一个选项，但是：

• 它并不是特别的Python式的-不像一段时间的理解那么易读
• 它可能没有CPython理解的效率和速度那么快
• 它需要一个额外的步骤来转换输出，而这可以直接放入理解中，例如[x.lower() for x in mylist]
• 甚至是original author doesn't seem to like it much。在

我的问题是，对于为什么将语法扩展到这个用例中不是一个好主意，还是因为python开发人员认为它很少有用而不可能这样做，是否有任何理论上的缺陷？它看起来像是对语言的一个简单的补充，也是一个有用的特性，但我可能忽略了一些隐藏的微妙之处或复杂性。在

相关：this和{a3}

Answer 1

正如@Paul McGuire所指出的，它是由Guido在PEP 3142和{a2}中提出的：

I didn't know there was a PEP for that. I hereby reject it. No point wasting more time on it.

不过，他没有给出解释。在邮件列表中，反对它的一些观点是：

• “[理解是]在多个嵌套语句和单个表达式之间精心设计的1对1转换。但这项提议忽视并打破了这一点。（here）。“也就是说，while关键字与显式循环中的while不对应，它只是一个break。在
• “它使Python更难学习，因为它又增加了一个要学习的东西。”（citatedhere）
• 它增加了生成器表达式和列表理解之间的另一个区别。似乎将此语法添加到列表理解中也是绝对不可能的。在

我认为与通常的列表理解的一个基本区别是while本质上是命令式的，而不是声明性的。它取决于并规定了执行顺序，而语言（AFAIK）不保证执行顺序。我想这就是为什么Haskell的理解中没有包含它，python从中窃取了这个想法。在

当然，生成器表达式确实有方向性，但它们的元素可能是预先计算的-同样，AFAIK。提到的政治公众人物确实提出，它只适用于生成器表达式，这是有意义的。在

当然，Python无论如何都是一种命令式语言，但它会带来问题。在

从一个不有序的集合中选择呢？在

[x for x in {1,2,3} while x!=2]

在简单的for循环中也没有它，但这是语言不能强制执行的。takewhile回答了这个问题，但这是一个武断的回答。在

---

最后一点，请注意，为了保持一致性，您需要对dropwhile的支持。有点像

^{pr2}$

这与等价的for结构没有太大关系，这次如果{}只是一个iterable，它就不可能短路。在