Windows NT shell + extended characters. Bug or what?

[Martin v. Loewis]

Wolfgang Strobl <ws at mystrobl.de> writes:

> >- as you point it, it fails for the raster fonts (for no apparent
> >  reason)
> 
> Carefull. The problem applies to _SetConsoleOutputCP, the reason being
> "SetConsoleOutputCP() is designed to change the mapping of the 256
> 8-bit character values into the glyph set of a fixed-pitch Unicode
> font, rather than loading a separate, non-Unicode font for each call to
> SetConsoleOutputCP(). " according to the Knowledge Base entry mentioned
> above. 

I can appreciate the desire not to load a new font each time. However,
I still think that the console could perform the conversion to the
OEMCP on output, displaying the replacement character for unsupported
characters.

> AFAIK there is no function OutputConsoleW.  Do you mean WriteConsoleW?

Oops, yes.

> >- it is tricky to determine reliably that a file descriptor is
> >  connected to a terminal.
> 
> I wouldn't want the python interpreter become dependent on whether the
> stdout file descriptor is connected to a console window  or not.
> Either always use the CPs of the console window associated with the
> current process, or never.

It wouldn't be that, but "either always use OutputConsoleW, or
never". I don't know what OutputConsoleW does when the file descriptor
is not a terminal.

> IMHO, a standard module which allows more control over platform
> specific parameters (like the code pages of the console window, if
> there is one) would be my prefered solution to this class of
> problems.

Certainly. The questions then are "what precisely is more control",
and "what precisely is this class of problems".

I believe Python should use Unicode API if it has a Unicode input. On
Win32, this applies to various situations: file names, registry,
environment variables, console output, and Tk output. Converting to
some codeset if the underlying environment converts it back to Unicode
is a stupid thing to do.

Regards,
Martin