That sounds like a bug magnet to me; my mental model is that the codec
is my output; flushing it will push things out, and resetting it will
erase anything pending.  I don't care if some implementation detail
means that some other object technically owns the buffer.

An alternative (inferior, but better than nothing) would be to add an
explicit note warning users that reset won't really finish the job,
and they have to also get the codec's underlying stream and flush
that.  (Of course, if the stream is really an abstraction over the
real stream ... at what point does the delegation start to work on its
own?)

On Tue, Jan 13, 2015 at 8:21 PM, Martin Panter <report@bugs.python.org> wrote:
>
> Martin Panter added the comment:
>
> I don’t think this is appropriate. If you want to flush the underlying stream, then call its flush() method after calling reset(). The docstring only says it flushes the _codec’s_ buffers, not any buffers of the underlying stream, and it should not be the codec’s business to worry about lower level buffers.
>
> ----------
> nosy: +vadmium
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue14014>
> _______________________________________