Jim Jewett added the comment: 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 <rep...@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 <rep...@bugs.python.org> > <http://bugs.python.org/issue14014> > _______________________________________ ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14014> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
