Repository navigation
unsynchronized write pointer in io.TextIOWrapper in 'r+' mode #82891
Description
| BPO | 38710 |
|---|---|
| Nosy | @vadmium, @MojoVampire |
| Superseder |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2019-11-06.04:04:15.160>
labels = ['3.7', 'type-bug', 'library', 'expert-IO']
title = "unsynchronized write pointer in io.TextIOWrapper in 'r+' mode"
updated_at = <Date 2019-11-17.23:20:53.209>
user = 'https://bugs.python.org/ManuelIgnacioPrezAlcolea'bugs.python.org fields:
activity = <Date 2019-11-17.23:20:53.209>
actor = 'martin.panter'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)', 'IO']
creation = <Date 2019-11-06.04:04:15.160>
creator = 'Manuel Ignacio P\xc3\xa9rez Alcolea'
dependencies = []
files = []
hgrepos = []
issue_num = 38710
keywords = []
message_count = 2.0
messages = ['356089', '356835']
nosy_count = 3.0
nosy_names = ['martin.panter', 'josh.r', 'Manuel Ignacio P\xc3\xa9rez Alcolea']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = '12215'
type = 'behavior'
url = 'https://bugs.python.org/issue38710'
versions = ['Python 3.7']
Activity
ManuelIgnacioPrezAlcolea commentedon Nov 6, 2019
There seems to be a bug in the
io.TextIOWrapperclass while working in 'r+' mode, although I can't say the source of the problem is right there.The write pointer doesn't match
file.tell()after performing a read operation.For example, this file, consisting of 3 lines:
line one
line two
line three
Doesn't result in the expected modification running the following program:
Instad of
line one
Hello
wo
line three
It results in
line one
line two
line threeHello
But it works just fine if
f.seek(f.tell())is added the program, right before the write operation.There are several possible explanations on StackOverflow, involving the buffering for IO in text files:
https://stackoverflow.com/a/58722058/11601118
vadmium commentedon Nov 17, 2019
Previously bpo-12215 and a couple of other duplicates were opened about this. Writing after reading with TextIOWrapper doesn't work as people expect. The report was closed apparently because Victor thought there wasn't enough interest in it.
FWIW the seek-then-write workaround will probably work for most common codecs, but would suffer the same problems discussed in bpo-26158 for codecs like UTF-7 and ISO-2022 that would need the encoder state constructed from the decoder state.