控制太输出的结果是01

问题：代碼读了一个字符，指针应该到第二个字符的位置为什么写内容还是被追加到了文件的最后？

太长不看版结论：Python3之后的New /O行为实现了bufferd /O ，导致了这个看似奇怪的行为

在wrte后f.tell()已经是原来的文件长+新写入的字符长了

这个问题在文件操作中，也就是APUE里的一个普通的seek问题我们可以看看为什么在Python3、在哪里导致的这样的问题

而不再是Python2里的内建函数了

下划线开头的这个_o是一个c模块：

它是用来提供流处理的接口的，继承关系什么的在上面的链接里有说

这篇PEP设计了一个三层的Python3 O实现：raw层、Buffer层、Text层，我们通常直接用的Text层告诉我们，打开一个流对象后（例如Open)这個对象会有一个buffer属性。作为缓冲层对应的对象
上面贴的代码描述了当wrte调用时，实际上调用的是self->buffer的写相关的方法

可以看到，虽然我们只讀了一个字符但实际上这个文件对应的buffer对象，指针已经指到了这个文件的末尾所以当调用wrte方法时，对这个buffer进行写也就写到了文件末尾在常见的操作系统上，这个buffer预取的长度是8k以减少磁盘的随机读取，增加磁盘的顺序读取

这一点在Python中可以得到验证：

现在符合直觉了攵件内容已经是hLove world 了～

由此得到了开头的结论：Python3和Python2的文件行为不一致是文件buffer造成的,buffered O本身是为了解决读取文件的效率问题。（PEP中说是为了和Java看齊。俺不懂什么java不知道java会不会有这个问题。

然后还更加优越2333

但我找了一下open函数的文档和对应的实现，没有找到改这个参数的地方～