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 ezio.melotti, martin.panter, pitrou, r.david.murray, socketpair, vstinner
Date 2015-12-15.03:20:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1450149644.09.0.29375769817.issue25849@psf.upfronthosting.co.za>
In-reply-to
Content
You might be right about the “reconstruction algorithm”. This text was added in revision 0bba533c0959; maybe Antoine can comment whether we should clarify or remove it.

I think the text added for TextIOBase.seek() in revision 03e61104f7a2 (Issue 12922) is closer to the truth. Though I would probably drop the bit about tell() not usually returning a byte position; for many codecs it does seem to.

This illustrates the only four cases of seeking I understand are allowed for text streams:

>>> text = TextIOWrapper(BytesIO(), "utf-7")
>>> text.write("привет")
6
>>> text.seek(0)  # 1: Rewind to start
0
>>> text.read(1)
'п'
>>> saved = text.tell()
>>> text.read()
'ривет'
>>> text.seek(saved)  # 2: Seek to saved offset
340282368347045388720132684115559317504
>>> text.read(1)
'р'
>>> text.seek(0, SEEK_CUR)  # 3: No movement
680564735267983852183507291547327528960
>>> text.read(1)
'и'
>>> text.seek(0, SEEK_END)  # 4: Seek to end
18
>>> text.read()  # EOF
''

If the “slow reconstruction algorithm” was clarified or removed, and the documentation explained that you cannot seek to arbitrary characters without having previously called tell(), would that work?
History
Date User Action Args
2015-12-15 03:20:44martin.pantersetrecipients: + martin.panter, pitrou, vstinner, ezio.melotti, r.david.murray, socketpair
2015-12-15 03:20:44martin.pantersetmessageid: <1450149644.09.0.29375769817.issue25849@psf.upfronthosting.co.za>
2015-12-15 03:20:44martin.panterlinkissue25849 messages
2015-12-15 03:20:42martin.pantercreate