This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients lemburg, ncoghlan, tleeuwenburg
Date 2011-08-22.05:30:25
SpamBayes Score 1.9138763e-10
Marked as misclassified No
Message-id <1313991026.57.0.929300839495.issue12808@psf.upfronthosting.co.za>
In-reply-to
Content
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
History
Date User Action Args
2011-08-22 05:30:26ncoghlansetrecipients: + ncoghlan, lemburg, tleeuwenburg
2011-08-22 05:30:26ncoghlansetmessageid: <1313991026.57.0.929300839495.issue12808@psf.upfronthosting.co.za>
2011-08-22 05:30:25ncoghlanlinkissue12808 messages
2011-08-22 05:30:25ncoghlancreate