On 8 May 2017 at 15:34, Nick Coghlan email@example.com wrote:
On 7 May 2017 at 15:22, INADA Naoki firstname.lastname@example.org wrote:
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.