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 James Hennessy, martin.panter, r.david.murray, serhiy.storchaka
Date 2016-04-19.03:54:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1461038052.98.0.975308894485.issue26730@psf.upfronthosting.co.za>
In-reply-to
Content
According to Issue 12215, the TextIOWrapper.tell() position only includes decoder state, not encoder state. So we may be lucky that tell() is proportional to the file size. If so my concern about max_size isn’t so important. But it still feels like a bad hack.

Maybe another quick fix for this would be to do two writes of the StringIO data, and then seek back to the end of the first write:

pos = file.tell()  # StringIO position is in code points
file.seek(0)
newfile.write(file.read(pos))
pos = newfile.tell()  # TextIOWrapper position is opaque
newfile.write(file.read())
newfile.seek(pos, 0)

This still depends on StringIO.tell() corresponding to the number of code points, which is undocumented (we already disable newline translation in the StringIO). See also Issue 25190.
History
Date User Action Args
2016-04-19 03:54:13martin.pantersetrecipients: + martin.panter, r.david.murray, serhiy.storchaka, James Hennessy
2016-04-19 03:54:12martin.pantersetmessageid: <1461038052.98.0.975308894485.issue26730@psf.upfronthosting.co.za>
2016-04-19 03:54:12martin.panterlinkissue26730 messages
2016-04-19 03:54:12martin.pantercreate