为什么列表推导会写入循环变量，而生成器却不会？

Question

如果我使用列表推导方法执行操作，它将写入局部变量：

i = 0
test = any([i == 2 for i in xrange(10)])
print i

打印“ 9”。但是，如果使用生成器，则它不会写入局部变量：

i = 0
test = any(i == 2 for i in xrange(10))
print i

打印“ 0”。

有什么很好的理由可以做到这一点吗？这是设计决定，还是只是生成器和列表理解的实现方式的随机副产品？就个人而言，如果列表推导不写入局部变量，对我来说似乎更好。

Answer 1

Python的创建者Guido van Rossum在写关于统一内置在Python 3中的生成器表达式时提到了这一点：

我们还对Python 3进行了另一项更改，以改善列表理解与生成器表达式之间的等效性。在Python
2中，列表理解将“循环”控制变量“泄漏”到周围的范围内：

x = 'before'
a = [x for x in 1, 2, 3]
print x # this prints '3', not 'before'

这是列表理解的原始实现的产物。
多年来，它一直是Python的“肮脏的小秘密”之一。它起初是一种有意的折衷，目的是使列表理解迅速变得盲目，虽然对于初学者来说这不是一个常见的陷阱，但它肯定偶尔会刺伤人们。
对于生成器表达式，我们无法执行此操作。生成器表达式是使用生成器实现的，生成器的执行需要单独的执行框架。因此，生成器表达式（特别是如果它们在短序列上进行迭代）比列表理解效率低。

但是，在Python 3中，我们决定通过使用与生成器表达式相同的实现策略来修复列表理解的“肮脏的小秘密”。因此，在Python
3中，上述示例（在修改为使用print（x）：-之后）将打印“ before”，证明列表理解中的“ x”会暂时遮蔽但不会覆盖周围的“ x”范围。

因此，在Python 3中，您将不再看到这种情况。

有趣的是，Python 2中的 dict理解 也不会这样做。这主要是因为dict理解是从Python 3向后移植的，因此已经在其中进行了修复。