--- "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
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