➜

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 paul.moore
Recipients docs@python, eryksun, lys.nikolaou, paul.moore, steve.dower, tim.golden, zach.ware
Date 2018-11-30.09:58:49
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1543571929.76.0.788709270274.issue30410@psf.upfronthosting.co.za>
In-reply-to
Content
The proposed wording seems a bit over-complex to me. Maybe the following re-wording would be easier to understand?

    The character encoding is platform-dependent. Non-Windows 
    platforms use the locale encoding (see 
    locale.getpreferredencoding()).

    On Windows, UTF-8 is used for the console device.  Non-character
    devices such as disk files and pipes use the system locale
    encoding (i.e. the ANSI codepage).  Non-console character
    devices such as NUL (i.e. where isatty() returns True) use the
    value of the console input and output codepages at startup,
    respectively for stdin and stdout/stderr. This defaults to the
    system locale encoding if the process is not initially attached
    to a console.

    The special behaviour of the console can be overridden
    by setting the environment variable PYTHONLEGACYWINDOWSSTDIO
    before starting Python. In that case, the console codepages are
    used as for any other character device.

    Under all platforms, you can override this value by
    setting the PYTHONIOENCODING environment variable before
    starting Python. However, for the Windows console, this
    only applies when PYTHONLEGACYWINDOWSSTDIO is also set.
History
Date User Action Args
2018-11-30 09:58:49paul.mooresetrecipients: + paul.moore, tim.golden, docs@python, zach.ware, eryksun, steve.dower, lys.nikolaou
2018-11-30 09:58:49paul.mooresetmessageid: <1543571929.76.0.788709270274.issue30410@psf.upfronthosting.co.za>
2018-11-30 09:58:49paul.moorelinkissue30410 messages
2018-11-30 09:58:49paul.moorecreate