--- "M.-A. Lemburg" <mal@lemburg.com> wrote:

Guido van Rossum wrote:

...

I don't know where this came from, but a flush() should work like flush() on a file.

It came from Fredrik's proposal.

...

It doesn't return a value, it just sends any remaining data to the underlying stream (for output). For input it shouldn't be supported at all.

The idea is that flush() should do the same to the encoder state that close() followed by a reopen() would do. Well, more or less. But if the process were to be killed right after a flush(), the data written to disk should be a complete encoding, and not have a lingering shift state.

This could be useful in real life. For example, iso-2022-jp has a 'single-byte-mode' and a 'double-byte-mode' with shift-sequences to separate them. The rule is that each line in the text file or email message or whatever must begin and end in single-byte mode. So I would take flush() to mean 'shift back to ASCII now'. Calling flush and reopen would thus "almost" get the same data across. I'm trying to think if it would be dangerous. Do web and ftp servers often call flush() in the middle of transmitting a block of text? - Andy ===== Andy Robinson Robinson Analytics Ltd. ------------------ My opinions are the official policy of Robinson Analytics Ltd. They just vary from day to day. __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com