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