In 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()
I'm running all of this on window 11 with Spyder as the IDE. Someone suggested top stop caching but I'm not sure how to do that. I do remove all variables before start in Spyder
You are using the file in "text-mode" (no b in the mode parameter). The docs state
f.tell() returns an integer giving the file object’s current position in the file represented as number of bytes from the beginning of the file when in binary mode and an opaque number when in text mode.
It's an error in expectations that f.tell() returning 12 means that the actual file cursor is currently at byte position 12.
What has actually happened is that the file has been read beyond the end-of-line marker during the first f.readline(), but only the line itself was returned from the call; the rest of what has been read is being buffered behind the scenes, and the file-cursor has been pushed as far.