为什么截断不能正确默认为文件的当前位置？

Question

在对another question 的回答中，观察到一种奇怪的行为，特定于 Python 3。documentation for the truncate command 状态（强调我的）：

将流的大小调整为以字节为单位的给定大小（如果未指定大小，则为当前位置）。当前的流位置没有改变。这种调整大小可以扩展或减小当前文件大小。在扩展的情况下，新文件区域的内容取决于平台（在大多数系统上，附加字节是零填充的）。 返回新的文件大小。

不过……

>>> open('temp.txt', 'w').write('ABCDE\nFGHIJ\nKLMNO\nPQRST\nUVWXY\nZ\n')
32
>>> f = open('temp.txt', 'r+')
>>> f.readline()
'ABCDE\n'
>>> f.tell()
6                   # As expected, current position is 6 after the readline
>>> f.truncate()
32                  # ?!

不是在当前位置 (6) 截断，而是在文件末尾截断（即根本不截断）。这是通过检查磁盘上的文件来验证的。

此过程在 Python 2 中按预期工作（文件被截断为 6 个字节），并且在 Python 3 中使用 StringIO 而不是文件。为什么 Python 3 中的文件不能按预期工作？这是一个错误吗？

（编辑：如果在truncate 之前给出明确的f.seek(6)，它也可以正常工作。）

Answer 1

>>> open('temp.txt', 'w').write('ABCDE\nFGHIJ\nKLMNO\nPQRST\nUVWXY\nZ\n')
32
>>> f = open('temp.txt', 'r+')
>>> f.readline()
'ABCDE\n'
>>> f.seek(6) 
>>> f.truncate()

如果没有其他问题，这可以解决问题，至于为什么会发生这种情况我不知道，但如果还没有报告这个上游，那将是一件好事。

这些是我能找到的与 Python3 和 Python2 之间的 truncate() 函数的唯一结构差异（显然，截断函数本身内的相关函数调用除外）：

33,34c33,34
<             except AttributeError as err:
<                 raise TypeError("an integer is required") from err
---
>             except AttributeError:
>                 raise TypeError("an integer is required")
54c54
<         """Truncate size to pos, where pos is an int."""
---
>         """Truncate size to pos."""

我相信有人会在这个问题上打我的耳光，但我认为这与flush() 调用以及调用flush 后缓冲区的处理方式更相关。几乎就像在刷新所有 I/O 后它没有重置到之前的位置一样。这是一个疯狂的假设，目前还没有技术支持，但这是我的第一个猜测。

查看flush()的情况，这里是两者的唯一区别，其中Python2执行了Python3没有的以下操作（甚至缺少它的源代码）：

def _flush_unlocked(self):
    if self.closed:
        raise ValueError("flush of closed file")
    while self._write_buf:
        try:
            n = self.raw.write(self._write_buf)
        except BlockingIOError:
            raise RuntimeError("self.raw should implement RawIOBase: it "
                               "should not raise BlockingIOError")
        except IOError as e:
            if e.errno != EINTR:
                raise
            continue
        if n is None:
            raise BlockingIOError(
                errno.EAGAIN,
                "write could not complete without blocking", 0)
        if n > len(self._write_buf) or n < 0:
            raise IOError("write() returned incorrect number of bytes")
        del self._write_buf[:n]

这是BufferedWriter 的函数，似乎在此 I/O 操作中使用。
现在我约会迟到了，所以必须冲刺，看看你们在此期间发现了什么会很有趣！

Answer 2

为此，我在 Python 问题跟踪器上打开了an issue，答案似乎与缓冲有关：

>>> open('temp.txt', 'w').write('ABCDE\nFGHIJ\nKLMNO\nPQRST\nUVWXY\nZ\n')
32
>>> f = open('temp.txt', 'r+')
>>> f.readline()
'ABCDE\n'
>>> f.tell()
6
>>> f.buffer.tell()
32

出于某种原因，truncate 使用缓冲区位置，而不是高级流位置。这实际上不仅限于truncate，还会产生其他意想不到的结果，例如：

>>> open('temp.txt', 'w').write('ABCDE\nFGHIJ\nKLMNO\nPQRST\nUVWXY\nZ\n')
32
>>> f = open('temp.txt', 'r+')
>>> f.readline()
'ABCDE\n'
>>> f.write('test')
4
>>> f.close()
>>> open('temp.txt').read()
'ABCDE\nFGHIJ\nKLMNO\nPQRST\nUVWXY\nZ\ntest'

一位开发人员has stated 说这里有一个问题，尽管我不能从他的陈述中完全确定问题是什么。不过，它似乎被标记为要修补。