Distro packagers have narrower user bases and a better known set of compatibility constraints than upstream, so kicking platform integration related config decisions downstream to us(/them) is actually a pretty reasonable thing for upstream to do :)

For example, while I've been iterating on the reference implementation for 3.7, Charalampos Stratakis has been iterating on the backport patch for Fedora 26, and he's found that we really need the PEP's "disable the C locale warning" config option to turn off the CLI's coercion warning in addition to the warning in the shared library, as leaving it visible breaks build processes for other packages that check that there aren't any messages being emitted to stderr (or otherwise care about the exact output from build tools that rely on the system Python 3 runtime).

However, when it comes to choosing the upstream config defaults, it's important to keep in mind that one of the explicit goals of the PEP is to modify PEP 11 to *formally drop upstream support* for running Python 3 in the legacy C locale without using PEP 538, PEP 540 or a combination of the two to assume UTF-8 instead of ASCII for system interfaces.

It's not that you *can't* run Python 3 in that kind of environment, and it's not that there are never any valid reasons to do so. It's that lots of things that you'd typically expect to work are going to misbehave (one I discovered myself yesterday is that the GNU readline problems reported in interactive mode on Android also show up when you do either "LANG=C python2" or "LANG=C python3" on traditional Linux and attempt to *edit* lines containing multi-byte characters), so you really need to know what you're doing in order to operate under those constraints.

Cheers,

Nick.

--