[Python-Dev] Late Python 3.7.1 changes to fix the C locale coercion (PEP 538) implementation

[Nick Coghlan]

On Wed, 19 Sep 2018 at 22:07, Victor Stinner <vstinner at redhat.com> wrote:
>
> > IMHO the implementation is really a secondary concern here, the main
> > question is: what is the correct behavior?
> >
> > Nick:
> >
> > * Do we agree that we need to provide a way to disable C locale
> > coercion (PEP 538) even when -E is used?
> > * Do you agree that Py_Initialize() and Py_Main() must not enable the
> > C locale coercion (PEP 538)?
> >
> > I understood that your reply is yes for the second question, since you
> > insist to push your change which also prevent Py_Initialize() and
> > Py_Main() to enable C locale coercion.
>
> Hum, I'm not sure if I explained properly my opinion on these questions.
>
> I consider that Python 3.7.0 introduced a regression compared to
> Python 3.6: it changes the LC_CTYPE locale for Python and all child
> processes and it's not possible to opt-out for that when using -E
> command line option.

This *wasn't* broken in the original PEP 538 implementation - it was
only broken when you ignored the PEP and tried to make everything work
the same way PEP 540 did, including moving the coercion out of the
Python CLI and into the runtime library APIs.

I still think the locale coercion handling in Python 3.7.x is broken,
but adding MORE code is NOT the right answer: going back to the
original (correct) implementation is.

So changing it back to the way the PEP is supposed to work is fine,
making everything more complicated for no good reason whatsoever is
not fine.

What changed is the fact I decided it wasn't worth holding up 3.7.1
over (and it certainly isn't worth adding a new -X option in a point
release).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia