Reading / writing...

[Chris Gonnerman]

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

> 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 newcenturycomputers.net
http://newcenturycomputers.net