Issue 6268: Seeking to the beginning of a text file a second time will return the BOM as first character (original) (raw)

Issue6268

Created on 2009-06-11 18:26 by eggy, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (5)
msg89257 - (view)	Author: Mark Florisson (eggy) *	Date: 2009-06-11 18:26
>>> f = open('foo', 'wt+', encoding='UTF-16') >>> f.write('spam ham eggs') 13 >>> f.seek(0) 0 >>> f.read() 'spam ham eggs' >>> f.seek(0) 0 >>> f.read() '\ufeffspam ham eggs' Although the BOM character is a ZERO WIDTH NO-BREAK SPACE, and should therefore not impose many problems, the behavior is inconsistent and unexpected. codecs.open in 2.x suffers from this same behavior.
msg89258 - (view)	Author: Antoine Pitrou (pitrou) *	Date: 2009-06-11 18:33
This is fixed in 3.1.
msg106282 - (view)	Author: STINNER Victor (vstinner) *	Date: 2010-05-22 02:17
Fixed: 2.7 (r81459), 2.6 (r81460), 3.2 (r81461), 3.1 (r81462).
msg106283 - (view)	Author: STINNER Victor (vstinner) *	Date: 2010-05-22 02:19
(For your information, io module had the same problem in Python3: it was fixed in #4862)
msg106316 - (view)	Author: STINNER Victor (vstinner) *	Date: 2010-05-22 17:05
> Fixed: 2.7 (r81459), 2.6 (r81460), 3.2 (r81461), 3.1 (r81462). This fix doesn't work on Windows nor Solaris: it uses "wt+" file mode, whereas "t" in invalid on these OS (does "t" mode really exist?). While fixing this bug, I noticed two other bugs (in StreamWriter). All bugs should be fixed by a new commit: 2.7 (r81471+r81472), 2.6 (r81473), 3.2 (r81474), 3.1 (r81475).