Home Original page

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

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 LC_DATE=ja_JP.UTF-8`, locale coercion may
>>   overrides LC_DATE.
>
> The fact it sets "LC_ALL" 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