使用上下文管理器自动关闭文件是python中常见的习惯用法：
with open('filename') as my_file:
# do something with my_file
# my_file gets automatically closed after exiting 'with' block
现在我想阅读几个文件的内容。数据的使用者不知道或不关心数据是来自文件还是非文件。它不想检查它收到的对象是否可以打开。它只是想从中获取内容。所以我创建了一个像这样的迭代器：
def select_files():
"""Yields carefully selected and ready-to-read-from files"""
file_names = [.......]
for fname in file_names:
with open(fname) as my_open_file:
yield my_open_file
这个迭代器可以像这样使用：
for file_obj in select_files():
for line in file_obj:
# do something useful
（注意，相同的代码可以用来消费不是打开的文件，但是字符串列表 - 这很酷！）
问题是：产生打开文件是否安全？
看起来像“为什么不呢？”。消费者调用迭代器，迭代器打开文件，将其产生给消费者。消费者处理文件并返回下一个迭代器。迭代器代码恢复，我们退出'with'块，my_open_file对象关闭，转到下一个文件等。
但是如果消费者永远不会回到下一个文件的迭代器呢？ F.E.消费者内部发生异常。或者消费者在其中一个文件中发现了一些非常令人兴奋的内容，并愉快地将结果返回给任何人调用它？
在这种情况下迭代器代码永远不会恢复，我们永远不会到'with'块结束，my_open_file对象永远不会被关闭！
或者它会吗？
答案 0 :(得分：15)
你提出了一个在 1 之前提出的批评。在这种情况下清理是不确定的，但是当生成器被垃圾收集时，将 与 CPython 一起发生。 对于其他python实现，您的里程可能会有所不同......
这是一个简单的例子：
from __future__ import print_function
import contextlib
@contextlib.contextmanager
def manager():
"""Easiest way to get a custom context manager..."""
try:
print('Entered')
yield
finally:
print('Closed')
def gen():
"""Just a generator with a context manager inside.
When the context is entered, we'll see "Entered" on the console
and when exited, we'll see "Closed" on the console.
"""
man = manager()
with man:
for i in range(10):
yield i
# Test what happens when we consume a generator.
list(gen())
def fn():
g = gen()
next(g)
# g.close()
# Test what happens when the generator gets garbage collected inside
# a function
print('Start of Function')
fn()
print('End of Function')
# Test what happens when a generator gets garbage collected outside
# a function. IIRC, this isn't _guaranteed_ to happen in all cases.
g = gen()
next(g)
# g.close()
print('EOF')
在CPython中运行此脚本，我得到：
$ python ~/sandbox/cm.py
Entered
Closed
Start of Function
Entered
Closed
End of Function
Entered
EOF
Closed
基本上，我们看到的是，对于耗尽的生成器，上下文管理器会在您预期时进行清理。对于未耗尽的生成器，清理函数在垃圾收集器收集生成器时运行。当发生器超出范围时（或最迟在下一个gc.collect周期进行IIRC），就会发生这种情况。
然而，做一些快速实验（例如在pypy中运行上述代码），我没有清理所有上下文管理器：
$ pypy --version
Python 2.7.10 (f3ad1e1e1d62, Aug 28 2015, 09:36:42)
[PyPy 2.6.1 with GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)]
$ pypy ~/sandbox/cm.py
Entered
Closed
Start of Function
Entered
End of Function
Entered
EOF
因此，上下文管理器的__exit__ 将为所有python实现调用的断言是不真实的。可能这里的失误归因于pypy's garbage collection strategy（其中不是引用计数）并且当pypy决定收获生成器时，该过程已经关闭，因此，它并没有打扰它...在大多数现实世界的应用程序中，生成器可能得到快速收割并最终确定它实际上并不重要......
如果您想保证您的上下文管理器已正确完成，那么当您完成 2 时，应该注意close生成器。取消注释上面的g.close()行给出了确定性清理，因为在GeneratorExit语句（在上下文管理器中）引发了yield，然后它被生成器捕获/抑制...
$ pypy ~/sandbox/cm.py
Entered
Closed
Start of Function
Entered
Closed
End of Function
Entered
Closed
EOF
$ python3 ~/sandbox/cm.py
Entered
Closed
Start of Function
Entered
Closed
End of Function
Entered
Closed
EOF
$ python ~/sandbox/cm.py
Entered
Closed
Start of Function
Entered
Closed
End of Function
Entered
Closed
EOF
FWIW，这意味着您可以使用contextlib.closing清理您的生成器：
from contextlib import closing
with closing(gen_function()) as items:
for item in items:
pass # Do something useful!
1 最近，一些讨论围绕着PEP 533，其目的是使迭代器清理更具确定性。
2 关闭已经关闭和/或消耗的发电机是完全可以的，这样你就可以调用它而不用担心发电机的状态。
答案 1 :(得分：7)
与＆＃39;结合使用是否安全？和＆＃39;产量＆＃39;在python？
我认为你不应该这样做。
让我演示制作一些文件：
>>> for f in 'abc':
... with open(f, 'w') as _: pass
说服自己，文件在那里：
>>> for f in 'abc':
... with open(f) as _: pass
这是一个重新创建代码的函数：
def gen_abc():
for f in 'abc':
with open(f) as file:
yield file
这里看起来你可以使用这个功能：
>>> [f.closed for f in gen_abc()]
[False, False, False]
但是，让我们首先创建所有文件对象的列表解析：
>>> l = [f for f in gen_abc()]
>>> l
[<_io.TextIOWrapper name='a' mode='r' encoding='cp1252'>, <_io.TextIOWrapper name='b' mode='r' encoding='cp1252'>, <_io.TextIOWrapper name='c' mode='r' encoding='cp1252'>]
现在我们看到它们全都关闭了：
>>> c = [f.closed for f in l]
>>> c
[True, True, True]
这仅在发电机关闭之前有效。然后文件全部关闭。
我怀疑这是你想要的，即使你正在使用延迟评估，你的最后一个文件可能会在你使用它之前关闭。