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 <1453258422.34.0.781972333269.issue12215@psf.upfronthosting.co.za>
In-reply-to
Content
Consider codecs that maintain an internal buffer (UTF-7) or other state (ISO-2022). When you call TextIOWrapper.read() 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?
History
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: <1453258422.34.0.781972333269.issue12215@psf.upfronthosting.co.za>
2016-01-20 02:53:42martin.panterlinkissue12215 messages
2016-01-20 02:53:41martin.pantercreate