STINNER Victor added the comment:
> This is a somewhat unfortunate difference between the major C libs and
> Python's new IO, but probably too late to change.
Well, it's easy to workaround it: just all file.seek(0, 2) after open() to
always to the end ;-) (or file.seek(0) to always go the begi
Georg Brandl added the comment:
This is a somewhat unfortunate difference between the major C libs and Python's
new IO, but probably too late to change.
What's left to do is to document the behavior properly.
--
assignee: -> docs@python
components: +Documentation -IO, Windows
nosy: +d
eryksun added the comment:
FYI, this is implementation defined in C89:
... unless the file is opened with append mode in which case
it is **implementation-defined** whether the file position
indicator is positioned at the beginning or the end of the
file.
http://port70.net/~n
Nick Jacobson added the comment:
For writing, end of file seems correct. But for reading, the documentation says
it should be the beginning of the file.
"The initial file position for reading is at the beginning of the file, but
output is always appended to the end of the file."
http://linux.
STINNER Victor added the comment:
Oh, fopen() behaves differently between "a" and "a+" mode on Linux: "a" goes to
the end, "a+" doesn't. It looks like a bug in the C library, or a bug in the
documentation?
"a+ mode:
Open for reading and appending (writing at end of file)"
http://linux.die.net/m
STINNER Victor added the comment:
Python 3 documentation is explicit about the "a" mode:
"open for writing, appending *to the end* of the file if it exists"
https://docs.python.org/dev/library/functions.html#open
Python 2 is based on the stdio.h of the C standard library which behaves
different
