理解与范围界定存在一些意外的相互作用。这是预期的行为吗？
我有一个方法：
def leave_room(self, uid): u = self.user_by_id(uid) r = self.rooms[u.rid] other_uids = [ouid for ouid in r.users_by_id.keys() if ouid != u.uid] other_us = [self.user_by_id(uid) for uid in other_uids] r.remove_user(uid) # OOPS! uid has been re-bound by the list comprehension above # Interestingly, it's rebound to the last uid in the list, so the error only shows # up when len > 1
冒着抱怨的危险，这是错误的残酷来源。在编写新代码时，偶尔会由于重新绑定而发现非常奇怪的错误-即使现在我知道这是一个问题。我需要制定一条规则，例如“始终在下划线的列表理解中使用temp vars开头”，但是即使这样也不是万无一失的。
这种随机定时炸弹等待的事实否定了列表推导的所有“易用性”。
列表推导泄漏了Python 2中的循环控制变量，但没有泄漏到Python 3中。这里是Guido van Rossum（Python的创建者）解释了其背后的历史：
我们还对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”范围。
