Nick Coghlan <ncogh...@gmail.com> added the comment: Tennessee, there were a few issues in the original patch - see the attached update (mostly the use of assert statements instead of methods and the overbroad scope of the context manager when checking for an expected exception).
However, in getting ready to commit this, I noticed something interesting. The docs for the IncrementalEncoder.getstate() API [1] state that the value returned *must* be an integer. BufferedIncrementalEncoder doesn't obey that limitation - when data is buffered, it returns the raw buffered string instead of encoding it as some kind of integer. As a separate, but related point, IncrementalDecoder.getstate() includes an explanation on how to save arbitrary state as an integer, but no such explanation (not even a reference to the IncrementalDecoder version) is present in the IncrementalEncoder.getstate() docs. Adding MAL, since I'd like an expert opinion. Is the API less stringent than the docs state, or should BufferedIncrementalEncoder be fixed to always return the state as an integer? [1] http://docs.python.org/dev/library/codecs#codecs.IncrementalEncoder.getstate ---------- nosy: +lemburg Added file: http://bugs.python.org/file22990/issue12808_codecs_coverage.diff _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12808> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
