Comment on PEP 263 - Defining Python Source Code Encodings

[Robin Becker]

In article <m3g00y94zj.fsf at mira.informatik.hu-berlin.de>, Martin v.
Loewis <martin at v.loewis.de> writes
>Robin Becker <robin at jessikat.fsnet.co.uk> writes:
>
>
>fileencoding=<name>
>
>which is syntax supported by vim. Unfortunately, in vim 6, this
>doesn't quite work: vim applies the setting at a time when it already
>has decided what encoding to use.
>

I already knew that in fact it seems to be the encoding flag that
determines things. I think fileencoding is used for possible conversion
of the file into the required encoding. Thus both 
gvim --cmd="set encoding=utf8" aaaa.txt
gvim --cmd="set encoding=utf8" aaaa.txt

display a utf8 file, aaaa.txt, correctly, but the latter has actually
converted the characters to latin1 (at least for me).

......
I must have missed this list somewhere.

>We do, see my list above. I expect that any editor that is "unicode
>aware" will support the UTF-8 signature, atleast when reading
>(hopefully also when writing).
>
>> As for the PEP itself the only snag seems to me to be the BOM + comment
>> problem. If I change the BOM by hitting saveAs myWeirdEncoding the file
>> is a dead python unless I also change the comment (or is that an issue
>> only with utf8 at present?).
>
>I'm not sure I understand the problem. If you do saveAs
>myWeirdEncoding, there won't be a BOM in the file unless
>myWeirdEncoding is UTF-8. If there are multiple conflicting encoding
>specifications in a file, the file is in error.
..... 

well I'm assuming that other standards like the utf8 BOM will eventually
be supported, but like you I hope utf8 wins out.
 
>Regards,
>Martin
>

-- 
Robin Becker