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. > > 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. >
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4