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 lemburg
Recipients lemburg, ncoghlan, tleeuwenburg
Date 2011-08-22.09:11:28
SpamBayes Score 3.2717328e-08
Marked as misclassified No
Message-id <4E521D3E.7060200@egenix.com>
In-reply-to <1313991026.57.0.929300839495.issue12808@psf.upfronthosting.co.za>
Content
Nick Coghlan wrote:
> 
> 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

I'm not sure how that description got into the docs. It must
have been added in the 3.x branch, since the 2.7 version of the
docs doesn't document those method at all.

FWIW: The .getstate() and .setstate() don't restrict the type of data
used for storing the state. The only requirement is that the data
returned by .getstate() can be passed to .setstate() in order to
recreate the internal state used by the codec:

    def getstate(self):
        """
        Return the current state of the encoder.
        """
        return 0

    def setstate(self, state):
        """
        Set the current state of the encoder. state must have been
        returned by getstate().
        """
For practical reasons, the used data should be pickleable.

The interface is very similar to the __getstate__/__setstate__
interface used by pickle.
History
Date User Action Args
2011-08-22 09:11:28lemburgsetrecipients: + lemburg, ncoghlan, tleeuwenburg
2011-08-22 09:11:28lemburglinkissue12808 messages
2011-08-22 09:11:28lemburgcreate