Windows NT shell + extended characters. Bug or what?

[Noel Smith]

Jeff Shannon wrote:
>> However I've recently installed python 7.2 on Windows NT4
> Wow!  7.2 ?  They really *have* sped up the release cycle...  <wink>

Doh! I was installing RedHat at the same time as writing the post. I meant
2.2 although it doesn't really matter what the version is.



Jason Orendorff wrote:
> Alas, the PC console uses a different character set called CP437,
> which is not Latin-1 compatible.  In CP437, the pound sign
> is 156 and the yen sign is 157.

This was the bit of info I was really after! I must admit that I hadn't ever
come across the "cp437" character set before, even though I've been doing
windows coding for a good few years now. Now I know about it I can just
apply a decode to a string to get the correct answer:

>>> ord( "£".decode("cp437") )
163



Martin V.  Loewis wrote:
> This is rather unlikely, I doubt the interactive interpreter will ever
> be able to properly identify the encoding of the console window. More
> likely, this line will give an error, since no encoding has been
> declared.

Although I agree that interpreter can't determine the encoding
automatically, it would be really nice to be able to set the input encoding
when you start it up. Its a real pain to look up the unicode value for every
extended character you want to use and it would make Python a lot easier for
those with a large number of extended characters on their keyboards.


Thanks for all the help.

Noel Smith