[Python-Dev] Small question about BufferedRandom spec

[Guido van Rossum]

On Mon, Jan 5, 2009 at 8:13 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> Guido van Rossum wrote:
>
>>> « Q: Do we want to mandate in the specification that switching between
>>> reading
>>> and writing on a read-write object implies a .flush()? Or is that an
>>> implementation convenience that users should not rely on? »
>>>
>>> Is it ok if I assume that the answer is "it is an implementation
>>> convenience
>>> that users should not rely on"? The reason is that I'm overhauling
>>> BufferedRandom objects to use a single shared buffer, so as to optimize
>>> interleaved reads and writes.
>>
>> I think it's fine if the flush to the file is optional, as long as
>> this is clearly documented. However, the semantics of interleaving
>> reads and writes, with and without seek calls in between, should be
>> well-defined and correct/useful, so that it behaves the same
>> regardless of the buffer size.
>
> I don't know how much of the stdio will be wrapped or replaced, but, FWIW,
> the C89 Standard, as described by Plauger & Brodie, requires a
> position-setting operation between writes and reads: one of fflush, fseek,
> fsetpos, or rewind.  Same for reads and writes unless the read set EOF.

We're not wrapping *any* of stdio -- we're wrapping raw Unix syscalls
(or Windows APIs). The problem with the C89 standard is that if you
forget this operation, the behavior is undefined, and I have seen
compliant implementations that would segfault in this case. That's
unacceptable for Python, and one of the reasons to bypass stdio
completely. (Other reasons include the absence of standardized APIs to
inspect the buffer, change buffering after starting I/O, peek ahead in
the buffer, seek within the buffer without flushing, etc.)

>> Ditto for the flush call currently implied by a seek -- if you can
>> satisfy the seek by moving where you are in the buffer without
>> flushing, that's fine IMO, but it should be well documented.
>>
>> It should also be documented that a flush still *may* occur, of course.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)