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 Zero, benjamin.peterson, docs@python, eryksun, fornax, martin.panter, pitrou, serhiy.storchaka, socketpair, steve.dower, stutzbach
Date 2016-01-20.03:04:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1453259091.43.0.179773064756.issue26158@psf.upfronthosting.co.za>
In-reply-to
Content
Fornax: Yes, I was suggesting the idea of deprecating truncate() for text files! Although a blanket deprecation of all cases may not be realistic. Quickly reading the Stack Overflow pages, it seems like there is demand for this to work in some cases. Deprecating it in the more awkward situations, such as after after reading, and with specific kinds of codecs, might be an option though.

Now I think Issue 12215 (read then write) is more closely related to the read-then-truncate problem. For the write-then-read bug, it might be a separate problem with an easy fix: call flush() before changing to reader mode.

Eryk: If there is no decoder state, and the file data hasn’t changed, maybe it is solvable. But I realize now it won’t work in general. We would have to construct the encoder state from the decoder state. The same problem as Issue 12215.
History
Date User Action Args
2016-01-20 03:04:51martin.pantersetrecipients: + martin.panter, pitrou, benjamin.peterson, stutzbach, Zero, docs@python, socketpair, serhiy.storchaka, eryksun, steve.dower, fornax
2016-01-20 03:04:51martin.pantersetmessageid: <1453259091.43.0.179773064756.issue26158@psf.upfronthosting.co.za>
2016-01-20 03:04:51martin.panterlinkissue26158 messages
2016-01-20 03:04:51martin.pantercreate