PEP 263 comments

[Martin v. Loewis]

"Neil Hodgson" <nhodgson at bigpond.net.au> writes:

>    How do you tell Python to treat stdout as a tty even though it is
> actually a pipe? I'd like to run Unicode printing programs from within SciTE
> with I/O redirected to SciTE's output pane. There is also an issue with
> stdin where I'd like to tell Python to treat redirected input, fed through a
> pipe, as a tty.

If stdout is a pipe, you cannot use the WriteConsoleW API for output,
I believe. So you *have* to perform some encoding, and unless you can
find a good reason to use a different one, the system default encoding
would be used.

In general, I see the usability to print Unicode only for the
interpreter prompt. In all other cases (including cases where output
goes to a pipe), the application should explicitly use some codec.
That would normally be the codec for the locale's encoding, something
that is roughly determined as

  if system is windows:
    terminal_encoding = "mbcs" # (1)
  elif have_nl_langinfo and have_CODEPAGE:
    terminal_encoding = locale.nl_langinfo(locale.CODEPAGE)
  else:
    terminal_encoding = sys.getdefaultencoding()

(1): This is actually incorrect. On the terminal, CP_OEMCP is used,
not CP_ACP (what "mbcs" uses). In the MS Console API, there are ways
to query and modify the code page of a console, which has no effect if
the raster font is used. 

If Python output goes to a pipe, I believe there is *no* way of
finding out what the right encoding should be: If the receiving end
writes to a text file, ANSI would be right, if the receiving end
prints to the console, OEM would be right - unless somebody has
changed the console code page for this console.

People are so used to characters not showing up correctly in a Windows
console that they won't worry if the application picks (1).

Regards,
Martin