Created on 2009-06-11 18:26 by eggy, last changed 2010-05-22 17:05 by haypo. 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 (haypo) * |
Date: 2010-05-22 02:17 | |
Fixed: 2.7 (r81459), 2.6 (r81460), 3.2 (r81461), 3.1 (r81462). |
|||
| msg106283 - (view) | Author: STINNER Victor (haypo) * |
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 (haypo) * |
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). |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2010-05-22 17:05:50 | haypo | set | messages: + msg106316 |
| 2010-05-22 02:19:09 | haypo | set | messages: + msg106283 |
| 2010-05-22 02:17:59 | haypo | set | status: open -> closed nosy: + haypo messages: + msg106282 resolution: fixed |
| 2009-06-11 18:33:53 | pitrou | set | priority: low versions: - Python 2.5, Python 2.4, Python 3.1, Python 3.2 nosy: + pitrou messages: + msg89258 |
| 2009-06-11 18:26:42 | eggy | create | |