问题标签 [generator-expression]

我编写了一个生成器函数，它以与 Excel 等电子表格应用程序中的列命名方案相同的方式生成无限的字符串序列，例如：

我的功能没有任何问题：

但是，我想把它变成一个更惯用的版本，它只使用生成器表达式，到目前为止我最好的镜头是这样的：

使用该生成器时，我得到一个运行时 TypeError ，它告诉我suffix变量的类型不被接受：

我的假设是它suffix应该是一个包含特定组合字母的元组，join并将其转换为字符串。我怎样才能让它正常工作，就像第一个功能一样？

如何与生成器表达式的值进行交互？例如：

当范围已知时（例如，我们知道范围是 [0,10)），我们可以放一个 for 循环，但是如果范围未知怎么办？

我有两种方法可以对文本文件中的数字求和。第一个有效，第二个无效。谁能解释第二个有什么问题？

输入文本文件：

方法#1：

这给出了正确答案 1368 (= 123 + 456 + 789)。

方法#2：

这会产生错误：

我正在玩生成器，所以问题实际上是关于为什么方法＃2 中的生成器不好。我不需要关于在文本文件中添加数字的其他方法的建议。我想知道是否有没有标准 for 循环的仅生成器解决方案。谢谢你。

假设有一个列表要处理，我不确定这两行代码是否具有相同的返回值：

此外，我可以替换sum(lst[i]...为sum(i...并仍然得到完全相同的结果吗？

所以我正在编写一些将部署在树莓派上的代码。由于 raspberry pi 的计算限制，以及它为此特定用途（图像捕获和处理）所采取的一系列步骤，我认为最好尽可能使用列表理解来代替 for 循环。如果可行，我设法创建了一个创建文件数组（名称+路径）的语句：

self.dark_file_names=np.array([(os.path.join(self.dark_frames_path, line.strip("\n")) for root, dirs, files in os.walk(self.dark_frames_path) for line in files if line.endswith(".npy\n"))])

但是，我在 ipython 中尝试了一个变体：

dark_file_names=np.array([(os.path.join(dark_frames_path, line.strip("\n")) for root, dirs, files in os.walk(dark_frames_path) for line in files if line.endswith(". py\n"))])

这是输出：

dark_frames_path 是一个包含大量 python 文件的本地目录

不幸的是，这不是我所希望的。我还尝试了一个具有类似结果的普通列表。为什么它将我的语句解释为生成器表达式而不是列表理解？

当我在 ipython 中使用这些命令通过 ssh 执行此操作时，我也有此工作：

ssh 是一个 paramiko.SSHClient() 实例。

我有一个字典列表，如下所示：

我写了一个生成器表达式，如：

现在奇怪的是，虽然这适用于键值对，'a' 但下次它会为所有其他表达式抛出错误。表达：

错误：

我有一个生成器函数，我想从另一个函数调用它并返回获得的生成器。我可以在这里看到两种方法 -

请注意，以下函数是用于说明目的的简单虚拟函数。请不要想出更好的方法来实现这些功能本身。

并用它list(list(fun_b(10))[0])来获得[10, 11, 12, 13, 14, 15, 16, 17, 18, 19]

然后list(fun_b(10))可以给我[10, 11, 12, 13, 14, 15, 16, 17, 18, 19]。

虽然方法 1 看起来不错，但我不想返回列表列表，因为在其他情况下我会返回列表并且我不想弄乱我的代码。方法2只是效率低下。

处理这种情况的真正好方法是什么？

考虑以下函数，其输出应该是一系列迭代的笛卡尔积：

当生成器推导被列表推导替换时工作正常。当只有 2 个可迭代对象时也可以使用。但是当我尝试

我明白了

为什么是这个而不是笛卡尔积？

据我所知，通过理解¹创建生成器的方法有三种。

经典之一：

变体yield：

变体（在函数内部yield from引发SyntaxErrorexcept ）：

这三种变体导致不同的字节码，这并不奇怪。第一个是最好的似乎是合乎逻辑的，因为它是通过理解创建生成器的专用、直接的语法。但是，它不是产生最短字节码的那个。

在 Python 3.6 中反汇编

经典生成器理解

yield变体

yield from变体

此外，timeit比较显示该yield from变体是最快的（仍然使用 Python 3.6 运行）：

f3f1大约是和的 2.7 倍f2。

正如Leon在评论中提到的，发电机的效率最好通过它可以迭代的速度来衡量。所以我改变了三个函数，让它们遍历生成器，并调用一个虚拟函数。

结果更加明显：

f3现在是 8.4 倍，是f19.3 倍f2。

注意：当可迭代对象不是静态可迭代对象时，结果或多或少是相同的range(10)，例如[0, 1, 2, 3, 4, 5]. range因此，速度的差异与以某种方式优化无关。

那么，这三种方式有什么区别呢？更具体地说，变体和其他两个有什么区别yield from？

这是自然构造(elt for elt in it)比棘手的慢的正常行为[(yield from it)]吗？从现在开始，我应该在我的所有脚本中用后者替换前者，还是使用该yield from构造有什么缺点？

编辑

这都是相关的，所以我不想提出一个新问题，但这变得更加陌生。我尝试比较range(10)和[(yield from range(10))]。

所以。现在，迭代[(yield from range(10))]速度是迭代裸机的 186 倍range(10)？

你如何解释为什么迭代[(yield from range(10))]比迭代快得多range(10)？

^{1：对于持怀疑态度的人，以下三个表达确实产生了一个generator对象；试着打电话type给他们。}

为什么结果不一样？