为什么在处理 Python 中以“r+”模式打开的文本文件对象时会观察到以下行为？

Question

我正在使用 Python 进行文件处理并尝试不同的文件模式。在文件模式为

'r+'

的特定场景中，我无法理解依次使用

read

和

write

方法时发生的情况（相对于文件指针的位置）。

我的测试文件的内容 （只有简单的 ASCII 字符）和我的互动 包含上述场景的Python解释器如下：

aTestTextFile3.txt：

012345678901234567890123456789

Python解释器：

>>> f = open('aTestTextFile3.txt', 'r+')

（文件指针位于开头）

>>> f.read()
'012345678901234567890123456789'

（文件指针在末尾）

>>> f.seek(0); f.write('MONTUEWED')
0
9

（文件指针最终到达位置9（考虑初始位置为0））

>>> f.seek(0); f.read()
0
'MONTUEWED901234567890123456789'

（文件指针终于到了最后）

>>> f.tell()
30

（当前文件指针位置已确认）

>>> f.seek(0); f.read(9)
0
'MONTUEWED'

（文件指针最终到达位置9（考虑初始位置为0））

>>> f.tell()
9

（当前文件指针位置已确认）

>>> f.write('THURS')
5
>>> f.tell()
35

（原来文件末尾写着“THURS”）

>>> f.seek(0); f.read()
0
'MONTUEWED901234567890123456789THURS'

（确认了上一点）

尽管

tell

方法调用指出在写入“THURS”之前文件指针的位置为 9，但“THURS”被写入到最后。为什么会这样呢？是因为前面的

read

方法调用吗？

（互动继续...）

>>> f.seek(0); f.read(9)
0
'MONTUEWED'

（文件指针终于指向9）

>>> f.tell()
9

（当前文件指针位置已确认）

>>> f.seek(0, 1)
9

（文件指针移动到当前位置，没有偏移，仍然是9，对吧？）

>>> f.write('THURS')
5

（本来我会认为“THURS”写在“WED”之后，但在之前的场景中，“THURS”写在最后；现在会发生什么？）

>>> f.tell()
14

（“THURS”写在“WED”之后，与之前的场景不同）

>>> f.seek(0); f.read()
0
'MONTUEWEDTHURS4567890123456789THURS'

（确认了前一点）

如果在

seek

方法调用之前至少有一个

write

方法调用，那么在进行

read

方法调用之前，文件指针是否应该始终使用

write

方法移动到其当前位置？ （我想如果回答了上一个问题，这个问题就会得到答案）

（互动继续...）

>>> f.seek(0); f.write('Greetings to thee!')
0
18

（文件指针终于到了位置18）

>>> f.read()
'890123456789THURS'

（确认了前一点）

>>> f.seek(0); f.read()
0
'Greetings to thee!890123456789THURS' 

在

read

方法调用之后使用

write

方法似乎没有问题。

Answer 1

>>> f.seek(0); f.read(9)
0
'MONTUEWED'

（文件指针最终到达位置 9（考虑到最初的 位置为 0))

>>> f.tell()
9

（当前文件指针位置已确认）

>>> f.write('THURS')
5
>>> f.tell()
35

（原来文件末尾写着“THURS”）

显然，Python 实现默认对混合读写施加了与 ANSI C 类似的限制 文件定位函数介入 输入和输出之间，上面违反了这一点。

文件指针是否应该始终移动到当前位置 在调用提供的

seek

方法之前使用

write

方法 在

read

方法之前至少有一个

write

方法调用 称呼？ （我想如果上一个问题这个问题就会得到回答 已回答）

是的，看起来是这样，虽然我没有看到它的记录。