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 martin.panter
Recipients Arfrever, BreamoreBoy, martin.panter, pitrou, terry.reedy, vstinner
Date 2016-01-20.02:53:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Consider codecs that maintain an internal buffer (UTF-7) or other state (ISO-2022). When you call and then tell(), the I think the returned number is supposed to hold the _decoder_ state, so you can seek back and read again. But I don’t think the number holds any _encoder_ state, so seek() cannot set up the encoder properly for these more awkward codecs.

I don’t think it is practical to fix this problem using the incremental codec API. You would need to construct the encoder’s state from the decoder. There are a couple of bugs marked as duplicates of this. What are the real-world use cases?
Date User Action Args
2016-01-20 02:53:42martin.pantersetrecipients: + martin.panter, terry.reedy, pitrou, vstinner, Arfrever, BreamoreBoy
2016-01-20 02:53:42martin.pantersetmessageid: <>
2016-01-20 02:53:42martin.panterlinkissue12215 messages
2016-01-20 02:53:41martin.pantercreate