Repository navigation
readline() causes output to be written at eof unless seek() is used #113439
Description
Bug report
Bug description:
# Add a code block here, if requiredIn python3 it seems that there is a bug with the readline() method.
I have a file txt.txt that contains two lines:
1234567890
abcdefghij
I then run the following code:
g = open("txt.txt","r+")
g.write("xxx")
g.flush()
g.close()
It modifies the file as expected:
xxx4567890
abcdefghij
I then run the following code:
g = open("txt.txt","r+")
g.readline()
Out[99]: 'xxx4567890\n'
g.tell()
Out[100] 12
g.write("XXX")
g.flush()
g.close()
I get the following:
xxx4567890
abcdefghij
XXX
Why is "XXX" being written to the end of the file instead of just after the first line?
If I run the following:
g = open("txt.txt","r+")
g.readline()
Out[99]: 'xxx4567890\n'
g.tell()
Out[100] 12
g.seek(12)
g.tell()
g.write("XXX")
g.flush()
g.close()
I get:
xxx4567890
XXXdefghij
XXX
seems like this is a bug in readline() - it says the cursor is at 12 but writes at EOF unless I use seek()
CPython versions tested on:
3.11
Operating systems tested on:
Windows
Activity
benjaminJohnson2204 commentedon Jan 14, 2024
I was able to reproduce this issue, and I'd like to work on fixing it.
I looked into the bug, and it seems like it's being caused by the
TextIOWrapperclass (in both the Cioand Pythonpyiomodules) reading an entire chunk at a time, then not rewinding its stream pointer before performing the write.Reproducing this example with opening a file in binary mode (as opposed to text) works as expected, rather than being buggy. The
TextIOWrapperclass, which is used for text file I/O, has its own buffer it reads an entire chunk into for everyreadorreadlinecall, and doesn't seek to the correct position when writing after reading. So I think theTextIOWrapperclass should be changed.The simplest fix would be to essentially add
self.seek(self.tell())to both the C and Python implementations ofTextIOWrapperwhenever we are writing to a stream that is readable and has a non-empty read buffer. For non-seekable streams, we may just want to leave the implementation as is (i.e. callingself.seek(self.tell())only if the stream is seekable). The only way I see to make this bug not occur for non-seekable streams would be to changeTextIOWrapperto not buffer itsreadcalls if it is both readable and writable, but not seekable.I'd be interested to hear other opinions on this.
vadmium commentedon Jul 26, 2024
Probably the same as Issue #82891 (and #56424, closed as not worth fixing)
StanFromIreland commentedon Apr 29, 2025
Duplicate: #117095
duaneg commentedon May 25, 2025
#93079 is another duplicate
picnixz commentedon May 25, 2025
Ok, so we haver many duplicates. I'll check which ones to close.