[Python-Dev] PEP 538 (review round 2): Coercing the legacy C locale to a UTF-8 based locale (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat Jun 17 02:39:49 EDT 2017

On 12 June 2017 at 22:05, Nick Coghlan <ncoghlan at gmail.com> wrote:

On 12 June 2017 at 17:47, Martin (gzlist) <gzlist at googlemail.com> wrote:

Having thought about it a bit more, my preferred option is having the disable be if either LCALL or LCCTYPE vars are exactly 'C', then don't override. Otherwise (including for LANG=C), force C.UTF-8. The CLI usage docs could have a LCCTYPE entry that goes into details of why. LCALL=C doesn't actually disable the locale coercion (i.e. we still set LCCTYPE). The coercion just doesn't have any effect, since LCALL takes precedence.

After improving the test suite to better cover this case, it seems my assumptions regarding the behaviour of setlocale() when LC_ALL is set may have been incorrect - when LC_ALL=C is set, we only get the legacy locale warning, not the locale coercion warning (at least on Fedora - we'll know more about the behaviour on other platforms once I test my proposed resolution for https://bugs.python.org/issue30565 across the buildbot fleet).

So if we chose to, we could treat an explicit "LC_CTYPE=C" the same way we treat "PYTHONCOERCECLOCALE=0" - it's definitely worth considering, so please file an RFE for that.

Cheers, Nick.

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

More information about the Python-Dev mailing list