Issue 19977 added "surrogateescape" to the fallback settings for the standard streams if Python 3 appears to be running under the POSIX locale (which Python 3 currently reads as setting a default encoding of ASCII, which is almost certainly wrong on any modern Linux system). If a modern Linux system is using systemd as the process manager, then there will likely be a "/etc/locale.conf" file providing settings like LANG - due to problematic requirements in the POSIX specification, this file (when available) is likely to be a better "source of truth" regarding the system encoding than the environment where the interpreter process is started, at least when the latter is claiming ASCII as the default encoding. See http://www.freedesktop.org/software/systemd/man/locale.conf.html for more details.
Why is the default encoding of POSIX wrong on a modern Linux system? Today I installed Debian testing, and the first question of the installer is to choose between "C" and "English" locales for the install. This with the remark that the chosen locale will be the default system locale.
That's the problem - even on UTF-8 systems, Linux programs will often be started in a misconfigured environment: the POSIX locale. Python 2 doesn't try to interpret the binary data as text, so it doesn't care. Python 3 *does* care, since it automatically converts several pieces of OS provided data to text using the locale encoding. systemd tackles that by adding the extra config file to ensure *all* the environments it creates get the right config, and to provide a more reliable "source of truth" as to the actual likely encoding of system interfaces. However, a fair bit of groundwork is needed to avoid any innate reliance on the locale encoding before we can reliably override it by default, so this issue is unlikely to go anywhere before PEP 432 is implemented (and even then, actually changing the behaviour would be a separate discussion).
While this is still a problem I'm interested in solving, I no longer think reading the systemd locale config file would be a good way to address it. See issue 28180 for a more recent discussion of some other alternatives.
