【CSDN 编者按】大家一起来找 Bug。

原文链接：

本文已获作者授权，未经允许，禁止转载！

作者 | Derek Rodriguez 译者 | 弯月
责编 | 夏萌出品 | CSDN（ID：CSDNnews）

最近，在解析文本时，我遇到了一个十分有趣的问题。在深入探讨之前，让我先来介绍一下背景故事。我的任务是分析文本文件中的一些以逗号分隔的数据，如下所示：

这个文本文件包含若干宽度可变的十六进制值，每行至少三个字段。我只关心第一个和第三字个段。在我看来，分析工作可分为三步：循环读取每一行数据；利用逗号将数据分解成一个列表；选取第一个和第三个元素，并将它们转换为整数。看似很简单，我可以使用 pandas DataFrame 编写几行代码就够了。下面是我编写的代码：

你发现 bug 了吗？反正我没看出来。下面，我来详细解释一下这段代码，并深入剖析我究竟错在哪儿了。

代码详解CSV文件是列表的列表我简单地认为，CSV 数据就是列表的列表。因此，我可以将各个元素视为嵌入列表。我从网上的一篇帖子中找到了读取嵌入列表的代码，然后复制粘贴：

nested_lists = [[1,2,3],[4,5,6],[7,8,9]]flattened_list = [element for sublist in nested_lists for element in sublist]

然后，我一些自己的代码进行扩展，最终得到了以下代码：

错误事实证明，Python 无法按照我的想象将可迭代的文本分解与推导式结合起来，你必须把 .split(",") 调用放在另一个列表中：

这让我有点伤脑筋，因为 .split(",") 本身就是一个列表，将它打包到另一个列表中，岂不变成了双重嵌套列表？我不太明白。我尝试通过编译器浏览器寻找答案。下图展示了正确的生成器表达式与我编写的代码之间的差异：

你看出问题所在了吗？代码中的问题在于，在分解文本之前，.split() 的返回值是迭代器。我不确定，但我相信这关系到最初提出列表推导式的建议时确立的实现细节。最后，我在 CPython 的贡献者 Crowthebird 的帮助下解决了这个问题，他演示了在不使用推导式的情况下重写代码的问题。错误的写法：

正确的写法：

这个问题可以得到解决吗？这实际上是因为我对 Python解释器的理解有错，解释器本身没有问题。我不认为按照我的理解修改语言会更好，因为如此很难区分在嵌套的情况下容器何时应该解构，何时应该重用，此外列表推导式会返回元组，而 PEP 202 规定不允许。

粉丝福利：