Python中的文件缓冲区刷新和关闭,可变重新分配 [英] File buffer flushing and closing in Python with variable re-assign

查看:235
本文介绍了Python中的文件缓冲区刷新和关闭,可变重新分配的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

对Python的文件缓冲有一个有趣的经验,并想知道我正确理解它。给定

[Python 2.7 shell]

  ... 
model =(非常大的Numpy模型)
f = open('file.out','w')
pickle.dump(model,f)
(pickle.dump()finish而我正在做其他事情)



[bash shell]

  $ ls -l 
-rw-r - r-- 1 john staff 270655488 Dec 6 21:32 file.out

[返回Python shell]

 <$ c 
f = open('newfile.out','w')
pickle.dump(model,f)
(pickle.dump() )完成)



[bash shell]

  $ ls -l 
-rw-r - r-- 1 john staff 270659455 Dec 7 07:09 file.out
-rw-r - r - 1 john staff 270659451 Dec 6 20:48 newfile.out

注意file.out现在是一个不同的大小。

现在,我知道Python的文件缓冲区默认为系统大小(我在Mac OSX上),所以似乎文件缓冲区中仍有3967字节而我正在搞砸,Mac OSX文件缓冲区大于此。



有趣的是我强制重新分配文件对象'f'到另一个打开文件没有真正调用f.close()(老实说,我只是工作非常快,测试其他和忘记)。当我查看文件大小时,我有一半预计它保持不变(这可能意味着截断输出)。因此,问题是这是否是一个安全的过程。文件对象的分配是这样一种方式,即使你没有调用close()方法,Python的垃圾回收器或文件对象本身也会刷新缓冲区并关闭文件,使其在突然变量重新赋值时关闭文件?更重要的是,这个总是是这种情况,或者实际上变量重新赋值可能 - 或者在另一种情况可能 - - 在文件缓冲区刷新之前截断该缓冲区。



我猜这是一个真正的问题,就是如果没有适当的文件对象和Python垃圾回收器,破坏。

解决方案

只要您的计算机没有崩溃,就不会因为不关闭文件而丢失数据。如果相应的文件对象被垃圾收集,Python确实会关闭文件。在您描述的情况下,名称 f 是该文件的唯一引用,因此当您将名称用于其他内容时它是关闭的。



请注意,最好关闭文件以释放由文件对象分配的系统资源。在某些情况下,您不清楚文件对象何时将被垃圾收集 - 例如,如果发生错误,可能会将对文件对象的引用存储在回溯对象中,从而阻止垃圾收集。所有文件在解释器退出时都会关闭。


Had an interesting experience with Python's file buffering and wanted to know that I understand it correctly. Given

[Python 2.7 shell]

...
model = (really big Numpy model)
f = open('file.out','w')
pickle.dump(model, f)
(pickle.dump() finishes while I'm doing other things)

[Bash shell]

$ ls -l
-rw-r--r--  1 john  staff  270655488 Dec  6 21:32 file.out

[Return to Python shell]

model = (different really big Numpy model)
f = open('newfile.out','w')
pickle.dump(model,f)
(pickle.dump() finishes)

[Bash shell]

$ ls -l
-rw-r--r--  1 john  staff  270659455 Dec  7 07:09 file.out
-rw-r--r--  1 john  staff  270659451 Dec  6 20:48 newfile.out

Note file.out is now a different size.

Now, I know that Python's file buffer defaults to the system size (I'm on Mac OSX), so it seems that there were still 3,967 bytes in the file buffer while I was screwing around, and the Mac OSX file buffer is greater than that.

What interested me was that I was forcibly reassigning the file object 'f' to another open file without actually calling f.close() (Honestly, I was just working really fast to test something else and forgot). When I looked at the file size, I half expected it to remain the same (which might mean truncating the output)

So, the question is whether this is a safe procedure. Is the file object assignment wrapped in such a way that either the Python garbage collector, or the file object itself, flushes the buffer and closes the file on such a sudden variable re-assignment even if you don't call the close() method? More importantly, is this always the case, or is it possible that the variable re-assignment actually did-- or in another situation might-- truncate that buffer before the file buffer flushed.

I guess it's really a question of how elegant and safe the file objects and Python garbage collector are when yanking objects around without appropriate destruction.

解决方案

As long as your computer does not crash, you won't lose data by not closing a file. Python does indeed close files if the corresponding file objects are garbage collected. In the case you described, the name f was the only reference to the file, so it was closed when you used the name for something else.

Note that it is good practice to close files anyway to free the system ressources allocated by the file object. In some situations you don't know exactly when a file object will be garbage collected -- for example in case of an error, a reference to the file object might be stored in the traceback object, preventing garbage collection. All files are closed when the interpreter exits.

这篇关于Python中的文件缓冲区刷新和关闭,可变重新分配的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆