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 lemburg
Recipients amaury.forgeotdarc, lemburg, pitrou, vstinner
Date 2009-01-08.13:50:49
SpamBayes Score 0.00024996523
Marked as misclassified No
Message-id <>
In-reply-to <>
On 2009-01-07 01:21, Amaury Forgeot d'Arc wrote:
> First write a utf-16 file with its signature:
>>>> f1 = open('utf16.txt', 'w', encoding='utf-16')
>>>> f1.write('0123456789')
>>>> f1.close()
> Then read it twice:
>>>> f2 = open('utf16.txt', 'r', encoding='utf-16')
>>>> print('read1', ascii(
> read1 '0123456789'
> 0
>>>> print('read2', ascii(
> read2 '\ufeff0123456789'
> The second read returns the BOM!
> This is because the zero in seek(0) is a "cookie" which contains both the position 
> and the decoder state. Unfortunately, state=0 means 'endianness has been determined: 
> native order'.
> maybe a suggestion: handle seek(0) as a special value which calls decoder.reset().
> The patch implement this idea.

This is a problem with the codec, not the io layer.
Opening a file in append mode is something that the io layer
would have to handle, since the codec doesn't know anything about
the underlying file mode.

Using .reset() will not help. The code for the StreamReader
and StreamWriter in will have to be modified to undo
the adjustment of the .encode() and .decode() method after using

Note that there's also the case .seek(1) - I guess this must
be considered as resulting in undefined behavior.
Date User Action Args
2009-01-08 13:50:51lemburgsetrecipients: + lemburg, amaury.forgeotdarc, pitrou, vstinner
2009-01-08 13:50:50lemburglinkissue4862 messages
2009-01-08 13:50:49lemburgcreate