[Python-Dev] PEP 538: Coercing the legacy C locale to a UTF-8 based locale

[Nick Coghlan]

On 13 March 2017 at 23:31, Random832 <random832 at fastmail.com> wrote:

> On Mon, Mar 13, 2017, at 04:37, INADA Naoki wrote:
> > But locale coercing works nice on platforms like android.
> > So how about simplified version of PEP 538?  Just adding configure
> > option for locale coercing
> > which is disabled by default.  No envvar options and no warnings.
>
> A configure option just kicks the decision to packagers - either no-one
> uses it (and thus it solves nothing) or people do use it (and any
> problems it causes won't be mitigated at all)
>

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.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170315/6ee9d125/attachment.html>