Eryk Sun added the comment:
It might be simplest to close this as 3rd party since it's similar to
bpo-29817. A workaround is to call f.seek(0, 1) to reset the stream state when
switching between reading and writing.
That said, a switch to writing at EOF should be supported. The problem is that
Python 2's file_read function in fileobject.c executes the following code in
this case:
if (bytesread < buffersize && !interrupted) {
clearerr(f->f_fp);
break;
}
clearerr() resets the EOF flag on the stream, so the Windows CRT has no way to
know that it's allowed to reset the buffer from read-mode to write-mode in the
subsequent write. Finally, Python raises a weird 'success' exception because
the CRT writes fewer than the number of requested bytes without setting errno.
AFAIK, this scenario only occurs on Windows. glibc on Linux appears to be more
robust in this case.
A simple way to demonstrate this without involving a debugger is to add a
second read() call before the write(). The 2nd read() takes a different path in
file_read(), which doesn't clear the stream's EOF flag.
import os, tempfile
fd, fn = tempfile.mkstemp()
os.write(fd, 'some text')
os.close(fd)
f = open(fn, 'r+')
>>> f.read()
'some text'
>>> f.read()
''
>>> f.write('more text')
>>> f.close()
>>> open(fn).read()
'some textmore text'
----------
nosy: +eryksun
type: -> behavior
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30460>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
