我们从一个测试开始。下面这个函数的功能是什么？

如果你觉得它的功能是“计算lst中所有元素的和与积”，不要沮丧。通常很难发现这里的错误。如果在大堆真实的代码中发现了这个错误就非常厉害了。——当你不知道这是一个测试时，很难发现这个错误。

这里的错误是在第二个循环体中使用了i而不是t。等下，这到底是怎么工作的？i在第一个循环外应该是不可见的? [1]哦，不。事实上，Python正式声明过，为for循环目标(loop target)定义的名称（更严格的正式名称为“索引变量”）能泄露到外围函数范围。因此下面的代码：

这段代码是有效的，可以打印出3。在本文中，我想探讨一下为什么会这样，为什么它不太可能改变，以及将它作为一颗追踪子弹来挖掘CPython编辑器中一些有趣的部分。

顺便说一句，如果你不相信这种行为可能会导致真正的问题，考虑这个代码片断：

如果你期待上面的代码能打印出[0，1，2，3]，你的期望会落空的，它会打印出[3,3,3,3]；因为在foo的作用域内只有一个i，这个i就是所有的lambda所捕获的。

官方说明

Python参考文档中的for循环部分明确地记录了这种行为：

for循环将变量赋值到目标列表中。……当循环结束时，赋值列表中的变量不会被删除，但如果序列是空的，它们将不会被赋值给所有的循环。

注意最后一句，让我们试试：

的确，上面的代码抛出NameError异常。稍后，我们将看到这是Python虚拟机执行字节码方式的必然结果。

为什么会是这样

其实我问过Guido van Rossum有关这个执行行为的原因，他很慷慨地告诉了我其中的一些历史背景（感谢Guido！）。这样执行代码的动机是保持Python获得变量和作用域的简单性，而不诉诸于hacks（例如在循环完成后，删除定义在该循环中的所有变量——想想它可能引发的异常）或更复杂的作用域规则。

Python的作用域规则非常简单、优雅：模块、类以及函数的代码块可引入作用域。在函数体内，变量从它们定义到代码块结束（包括嵌套的代码块如嵌套函数）都是可见的。当然，对于局部变量、全局变量（以及其他nonlocal变量）其规则略有不同。不过，这和我们的讨论没有太多关系。

这里最重要的一点是：最内层的可能作用域是一个函数体。不是一个for循环体。不是一个with代码块。Python与其他编程语言不同（例如C及其后代语言），在函数水平下没有嵌套词法作用域。

因此，如果你只是基于Python实现，你的代码可能会以这样的执行行为结束。下面是另一段令人启发的代码片段：

变量d 在for循环结束后是可见及可访问的，你对这样的发现感到惊奇吗？不，这正是Python的工作方式。那么，为什么索引变量的作用域被区别对待呢？

顺便说一句，列表推导式（list comprehension）中的索引变量也泄露到其封闭作用域，或者更准确的说，在Python 3之前可以泄露。

Python 3包含许多重大更改，其中也修复了列表推导式中的变量泄露问题。毫无疑问，这样破坏了向后兼容中性。这就是我认为当前的执行行为不会被改变的原因。

此外，许多人仍然发现这是Python中的一个有用的功能。考虑一下下面的代码：

如果不知道somegenerator返回项的数目，可以使用这种简洁的方式。否则，你就必须有一个独立的计数器。

这里有一个其他的例子：

这种模式可以有效的在循环中查找某一项并在随后使用该项。[2]

多年来，许多用户都想保留这种特性。但即使对于开发者认定的有害特性，也很难引入重大更改了。当许多人认为该特性很有用，而且在真实世界的代码中大量使用时，就更不会除去这项特性了。

Under the hood

现在是最有趣的部分。让我们来看看Python编译器和VM是如何协同工作，让这种代码执行行为成为可能的。在这种特殊的情况下，我认为呈现这些的最清晰方式是从字节码开始逆向分析。我希望通过这个例子来介绍如何挖掘Python内部[3]的信息（这是如此充满乐趣！）。

让我们来看本文开篇提出的函数的一部分：

如果你期待上面的代码能打印出[0，1，2，3]，你的期望会落空的，它会打印出[3,3,3,3]；因为在foo的作用域内只有一个i，这个i就是所有的lambda所捕获的。

官方说明

Python参考文档中的for循环部分明确地记录了这种行为：

for循环将变量赋值到目标列表中。……当循环结束时，赋值列表中的变量不会被删除，但如果序列是空的，它们将不会被赋值给所有的循环。

注意最后一句，让我们试试：

的确，上面的代码抛出NameError异常。稍后，我们将看到这是Python虚拟机执行字节码方式的必然结果。

为什么会是这样

其实我问过Guido van Rossum有关这个执行行为的原因，他很慷慨地告诉了我其中的一些历史背景（感谢Guido！）。这样执行代码的动机是保持Python获得变量和作用域的简单性，而不诉诸于hacks（例如在循环完成后，删除定义在该循环中的所有变量——想想它可能引发的异常）或更复杂的作用域规则。

Python的作用域规则非常简单、优雅：模块、类以及函数的代码块可引入作用域。在函数体内，变量从它们定义到代码块结束（包括嵌套的代码块如嵌套函数）都是可见的。当然，对于局部变量、全局变量（以及其他nonlocal变量）其规则略有不同。不过，这和我们的讨论没有太多关系。

这里最重要的一点是：最内层的可能作用域是一个函数体。不是一个for循环体。不是一个with代码块。Python与其他编程语言不同（例如C及其后代语言），在函数水平下没有嵌套词法作用域。

因此，如果你只是基于Python实现，你的代码可能会以这样的执行行为结束。下面是另一段令人启发的代码片段：

变量d 在for循环结束后是可见及可访问的，你对这样的发现感到惊奇吗？不，这正是Python的工作方式。那么，为什么索引变量的作用域被区别对待呢？

顺便说一句，列表推导式（list comprehension）中的索引变量也泄露到其封闭作用域，或者更准确的说，在Python 3之前可以泄露。

Python 3包含许多重大更改，其中也修复了列表推导式中的变量泄露问题。毫无疑问，这样破坏了向后兼容中性。这就是我认为当前的执行行为不会被改变的原因。

此外，许多人仍然发现这是Python中的一个有用的功能。考虑一下下面的代码：

如果不知道somegenerator返回项的数目，可以使用这种简洁的方式。否则，你就必须有一个独立的计数器。

这里有一个其他的例子：

这种模式可以有效的在循环中查找某一项并在随后使用该项。[2]

多年来，许多用户都想保留这种特性。但即使对于开发者认定的有害特性，也很难引入重大更改了。当许多人认为该特性很有用，而且在真实世界的代码中大量使用时，就更不会除去这项特性了。

Under the hood

现在是最有趣的部分。让我们来看看Python编译器和VM是如何协同工作，让这种代码执行行为成为可能的。在这种特殊的情况下，我认为呈现这些的最清晰方式是从字节码开始逆向分析。我希望通过这个例子来介绍如何挖掘Python内部[3]的信息（这是如此充满乐趣！）。

让我们来看本文开篇提出的函数的一部分：

产生的字节码是：