偏爱以下原因的确有一个原因：
with open('filename.txt') as fp: for line in fp: print line我们都为CPython的相对确定性的引用计数方案所迷惑。如果其他假设的Python实现
with使用某种其他方案来回收内存，则没有块时不一定会“迅速”关闭文件。
在这样的实现中，如果您的代码打开文件的速度比垃圾收集器在孤立的文件句柄上调用终结器的速度快，则可能会从OS收到“打开太多文件”错误。通常的解决方法是立即触发GC，但这是一个讨厌的技巧，必须由可能遇到错误的
每个 函数（包括库中的函数）来完成。什么样的恶梦。
或者，您可以只使用
with块。
奖金问题
（如果仅对问题的客观方面感兴趣，请立即停止阅读。）
为什么文件对象的迭代器协议中未包含该代码？
这是有关API设计的主观问题，因此我有两个部分的主观答案。
从直觉上讲，这是错的，因为它使迭代器协议执行两项独立的操作（遍历行 并
关闭文件句柄），并且使外观简单的函数执行两项操作通常是个坏主意。在这种情况下，感觉特别糟糕，因为迭代器以准功能，基于值的方式与文件内容相关联，但是管理文件句柄是完全独立的任务。对于阅读代码的人来说，将两者无形地压为一个动作是令人惊讶的，并使推理程序行为变得更加困难。
其他语言基本上得出了相同的结论。Haskell简短地调侃了所谓的“惰性IO”，它允许您遍历文件并在到达流末尾时自动将其关闭，但是如今，在Haskell和Haskell中几乎普遍不鼓励使用惰性IO。用户大多转向更明确的资源管理，例如Conduit，其行为更像
withPython中的块。
从技术上讲，您可能需要对Python中的文件句柄做一些事情，如果迭代关闭了文件句柄，这些操作将无法正常工作。例如，假设我需要遍历文件两次：
with open('filename.txt') as fp: for line in fp: ... fp.seek(0) for line in fp: ...虽然这是一种不太常见的用例，但请考虑以下事实：我可能刚刚将底部的三行代码添加到了原来具有前三行的现有代码库中。如果迭代关闭了文件，我将无法执行该操作。因此，将迭代和资源管理分开保持可以更轻松地将代码块组合成一个更大的，可运行的Python程序。
可组合性是语言或API最重要的可用性功能之一。
