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

Nick Coghlan ncoghlan at gmail.com
Mon May 8 23:44:11 EDT 2017

On 8 May 2017 at 15:34, Nick Coghlan <ncoghlan at gmail.com> wrote:

On 7 May 2017 at 15:22, INADA Naoki <songofacandy at gmail.com> wrote:

## Background

Locale coercion in current PEP 538 has some downsides: * If user set LANG=C LCDATE=jaJP.UTF-8, locale coercion may overrides LCDATE. The fact it sets "LCALL" has previously been raised as a concern with PEP 538, so it probably makes sense to drop that aspect and just override "LANG". The scenarios where it makes a difference are incredibly obscure (involving non-default SSH locale forwarding settings for folks using SSH on Mac OS X to connect to remote Linux systems), while just setting "LANG" will be sufficient to address the "LANG=C" case that is the main driver for the PEP.

It occurs to me we can even still handle the forwarded "LC_CTYPE=UTF-8" case by changing the locale coercion to set LC_CTYPE & LANG, rather than just setting LANG as I suggested above.

That way LANG=C LC_DATE=ja_JP.UTF-8 would still respect the explicit LC_DATE setting, LC_CTYPE=C would be handled the same way as LANG=C, and LC_ALL=C would continue to provide a way to force the C locale even for LC_CTYPE without needing to be aware of the Python specific PYTHONCOERCECLOCALE setting.

Cheers, Nick.

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

More information about the Python-Dev mailing list