既然你链接到了2.7文档,我假设你使用的是2.7。(在Python3.x中,这一切都变得简单得多,因为更多的缓冲是在Python级别公开的。)
所有的open实际上所做的(在POSIX系统上)就是调用fopen,然后,如果您已经为buffering传递了任何内容,setvbuf。因为您没有传递任何内容,所以您只得到来自fopen的默认缓冲区,这取决于您的C标准库。(详见the source。如果没有buffering,它会将-1传递给PyFile_SetBufSize,除非bufsize >= 0,否则它不会执行任何操作。)
如果您阅读glibc ^{} manpage,它将解释如果您从未调用任何缓冲函数:Normally all files are block buffered. When the first I/O operation occurs on a file, malloc(3) is called, and a buffer is obtained.
注意,它并没有说明获得的缓冲区大小。这是有意的;这意味着实现可以是智能的,并为不同的情况选择不同的缓冲区大小。(有一个BUFSIZ常量,但这只在调用setbuf之类的遗留函数时使用;它不能保证在任何其他情况下使用。)
那么,会发生什么?如果你查看GLUBC源,它最终调用宏^ {A3},它可以被钩住(或者被重写,因为GLUBC将C++ +流和C STDIO缓冲)结合起来,但是最终,它分配了一个^ {b13CD}}的BUF,这是平台特定宏^{}的别名,它是^ {CD15}}。
当然,您可能希望在自己的系统上跟踪宏,而不是信任通用源。
你可能想知道为什么没有好的记录方法来获取这些信息。大概是因为你不应该在意。如果您需要一个特定的缓冲区大小,可以手动设置;如果您相信系统最清楚,只需信任它。除非你真的在开发内核或libc,谁在乎呢?理论上,这也使得系统可以在这里做一些聪明的事情,比如根据文件系统的块大小选择bufsize,或者甚至基于运行的stats数据,尽管看起来不像linux/glibc、FreeBSD或OS X除了使用常量之外做任何事情。这很可能是因为这对大多数应用程序来说都无关紧要。(您可能希望自己测试一下,在一些缓冲的I/O绑定脚本上使用从1KB到2MB的显式缓冲区大小,并查看性能差异是什么。)