Reading / writing...

Chris Gonnerman chris.gonnerman at
Fri Jan 17 06:48:40 CET 2003

----- Original Message -----
From: "Andrew Thompson" <andrew.thompson at>

> Exactly, but to quote the Python Essential Reference (2000) guide,
> 'when a file is opened for update, you can perform both input and
> output, as long as all output operations flush their data before any
> subsequent input operations'

So, David Beazley oversimplified the situation.  Internally,
Python uses standard FILE * objects (in CPython anyway).

>From the man page for fopen(2) on my Linux system:

    Reads  and  writes  may  be intermixed on
    read/write streams in any order.  Note that
    ANSI C requires  that  a  file  positioning
    function  intervene between output and input,
    unless an input operation encounters end-of-
    file.  (If this condition is not met, then a
    read is allowed to return the result of
    writes other than the most recent.)
    Therefore it is good prac­tice (and indeed
    sometimes necessary under Linux) to put an
    fseek or fget­pos  operation  between  write
    and read operations on such a stream.  This
    operation may be an apparent no-op (as in
    fseek(..., 0L, SEEK_CUR)  called for its
    synchronizing side effect.

> What is happening here is that the write() simply doesn't write,
> (although the file pointer moves on)and no error condition is raised...
> (how might a user know to perform a seek() to effect the write() --
> without having extra-Pythonic knowledge ?)

Good question.  Most likely this should be revised (at
least a warning) in the standard documentation...  I just
checked the 2.1.2 docs on my home system, and they don't
mention these concerns at all.

> Shouldn't Python be able to hide this from its users ?

Possibly... but each platform has potentially different rules.
It's hard to know what to hide, and what to expose...

Chris Gonnerman -- chris.gonnerman at

More information about the Python-list mailing list