何时使用“快捷方式”：列表推导、生成器表达式、lambda 函数？ [关闭]答案

【问题标题】：When to use "shortcuts": list comprehensions, generator expressions, lambda functions? [closed]何时使用“快捷方式”：列表推导、生成器表达式、lambda 函数？ [关闭]
【发布时间】：2020-06-25 12:15:24
【问题描述】：

我开始工作并在数据分析方面更加熟悉 Python，并且刚刚了解了我认为非常优雅的列表推导。

虽然我知道以牺牲可读性为代价过分爱上它的风险，但我真的没有找到任何指导或经验法则来说明何时或何时不使用它。

在我自己的代码中，我在递归函数中使用了这个生成器表达式 --> find_children() 是一个用户定义的函数来创建分层数据

(find_children(ancestor) for ancestor in parents if len(parents) > 0)

而不是

if len(parents) > 0:
    for ancestor in parents:
        find_children(ancestor)

它看起来更整洁，但这实际上是我的唯一原因。

因此，我想收集一些经验丰富的 Pythonista 的意见以及他们对此的方法或最佳实践是什么。

【问题讨论】：

不要仅仅为了调用函数的副作用而使用可迭代对象。
脱离上下文，你的生成器表达式不会做任何事情，因为你没有迭代它。它只是创建了一个生成器，它会立即被丢弃，而无需调用 find_children。
当你想要一个列表时使用列表推导，而不是当你只想将普通的for 循环压缩到一行时。
好的，所以如果代码很简单，如果为了创建单行代码，你就不要这样做，我理解。在我的示例中，它确实与下面的 sn-p 有效地做同样的事情。它更像是一个程序而不是一个函数，不返回任何东西。
您从列表理解到常规 for 循环的翻译不正确。列表理解中的（可选）if过滤来自可迭代对象的输出。见这里：stackoverflow.com/a/15474952/1643973

标签： python lambda list-comprehension generator-expression

【解决方案1】：

列表推导式是惯用的 Python 代码，因此非常好。他们的主要竞争对手是使用 map()、filter() 等的函数式风格。两种风格都非常好。当你有很长的陈述时，我可能会避免使用列表推导，例如 x["data"]["data"]["data"] for x in something]自找麻烦。

嵌套列表推导也是邪恶的，我个人认为它们是一种代码味道，因为它们的可读性很差。

最后，好的代码的目标是可读性——当你写完一段代码后，退后一步，试着判断谁真正读懂了你的代码。引入函数和变量以增加可读性。列表推导式只是该图片的一部分。

【讨论】：

您能解决问题中的示例吗？这是一个不错的一般建议，但它并没有解决 OP 如何使用它们的任何问题。