文件是否关闭？ [英] Is the file closed?

问题描述

  filecontent = open（文件名）.read（）
  

我想知道在这种情况下由打开创建的文件对象是什么：是隐式关闭还是保持打开？

解决方案

在这种情况下打开创建的文件对象：是隐式关闭还是保持打开？

它一直保持打开状态直到垃圾收集器发现没有人可以访问它，并销毁它，在这一点上它是由析构函数关闭。

Python语言不保证什么时候会发生当然，除非你不能访问它）。

然而，CPython的实现（你可能使用的是，因为它是截至2013年5月仅工作3.x实施）使用参考计数（加上一个周期检测器）的垃圾收集，这意味着一旦最后一个引用消失（除非它涉及到某个周期的某个点），这个对象就会被销毁。

因此，在CPython中，大多数情况下，只要从函数返回，文件就会被关闭，为 filecontent 分配一个新值，或者 del filecontent 。而很多快速和肮脏的代码依赖于此。

但是Jython和IronPython依赖于Java / .NET垃圾收集器，它定期检查复杂和花哨的垃圾而不是随时进行追踪，所以不能保证何时收集到任何东西。 PyPy有多个选项，取决于它的配置。

即使在CPython中，在没有可见的 因为，例如，你在调试器中运行它，并以一些不可见的引用结束。或者，如果文件涉及引用周期，它可能永远不会被关闭。因此，你不应该依赖这个行为除快速和肮脏的代码之外的任何东西。基本上，如果文件保持打开状态直到你的程序结束，那就好了。

权利 的做法是用和 $ b $ pre $ ，以open（thefilename）作为f：
filecontent = f.read（）


这保证 f.close（）被调用只要带有语句结束。

每当人们经常提出一种方法将它变成一个在这种情况下，Guido总是以open（文件名）的形式回复类似于的文件，因为f：filecontent = f.read（）已经是一行代码了。但是远不及你所建议的那么糟糕。

但是，真的有更好的答案：写一个包装它的函数：

  def read_whole_file（filename）：
 with open（thefilename）as f：
 return f.read（）
  

然后：

  filecontent = read_whole_file（thefilename）
  

干净，简洁，可读...打开'em都没有任何借口，让GC排序黑客。

I see regularly this kind of code:

filecontent = open(thefilename).read()

I wonder what becomes the file object created by open in this situation: is it implicitly closed, or does it stay open somewhere ?

解决方案

I wonder what becomes the file object created by open in this situation: is it implicitly closed, or does it stay open somewhere ?

It stays open until the garbage collector discovers that nobody can access it anymore and destroys it, at which point it is closed by the destructor.

The Python language makes no guarantees as to when that will happen (except, of course, that it will be after you can't access it anymore).

However, the CPython implementation (which you're probably using, because it's the only working 3.x implementation as of May 2013) uses reference counting (plus a cycle detector) for its garbage collection, which means that as soon as the last reference goes away (unless it was involved in a cycle at some point), the object gets destroyed.

So, in CPython, in most cases, the file will get closed as soon as you return from the function, assign a new value to filecontent, or del filecontent. And a lot of quick&dirty code relies on this.

But Jython and IronPython rely on the Java/.NET garbage collector, which periodically checks for garbage in complicated and fancy ways instead of keeping track on the fly, so there is no guarantee as to when anything gets collected. And PyPy has multiple options, depending on how it's configured.

And, even in CPython, it's possible for garbage to stay around after there are no visible references because, e.g., you ran it in the debugger and ended up with some invisible references. Or, if the file was involved in a reference cycle, it may never get closed.

So, you should not rely on this behavior in anything except quick&dirty code. Basically, if it's acceptable that the file stay open until your program finishes, fine. Otherwise, don't do it.

The right way to do this is with a with statement:

with open(thefilename) as f:
    filecontent = f.read()

This guarantees that f.close() gets called as soon as the with statement finishes.

Every so often, people suggest a way to turn this into a one-liner, to which Guido always replies something like, "with open(thefilename) as f: filecontent = f.read() is already a one-liner. And it's kind of bad, but nowhere near as bad as what you're suggesting."

But really, there's an even better answer: Write a function that wraps it:

def read_whole_file(filename):
    with open(thefilename) as f:
        return f.read()

And then:

filecontent = read_whole_file(thefilename)

Clean, concise, readable… there's no excuse for the "open 'em all and let the GC sort 'em out" hack.

这篇关于文件是否关闭？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！