Walter Dörwald wrote:
But then incompleteness is always OK,
because the StreamReader can't distinguish a temporarily exhausted input stream from a permanently exhausted one. The only fix for this I can think of is the final argument.
I don't think the final argument is needed. Methinks that the .encode/.decode should not be used by an application. Instead, applications should only use the file API on a reader/writer.
If so, stateful readers/writers can safely implement encode/decode to take whatever state they have into account, creating new state as they see fit.
Of course, stateful writers need to implement their own .close function, which flushes the remaining bytes, and need to make sure that .close is automatically invoked if the object goes away.