bpo-18378: Recognize "UTF-8" as a valid name in locale._parse_localename by ronaldoussoren · Pull Request #14736 · python/cpython (original) (raw)

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation8 Commits2 Checks0 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

"UTF-8" is a valid value for LC_CTYPE on macOS, and the variable is set to that value during interpreter startup by the UTF-8 coercion code in pylifecycle.c.

https://bugs.python.org/issue18378

The pull-request enables recognition of "UTF-8" as a valid value on all platforms. I've primarily done this because the value of LC_CTYPE will usually leak into the target system when you use SSH to log on those systems.

Victor, I've asked for your review because you're involved with the code that sets LC_CTYPE during interpreter startup.

locale.getpreferredencoding() is based on nl_langinfo(CODESET) which is reliable.

I never understood the purpose of the locale.getdefaultlocale() function, especially locale._parse_localename(). What is the use case for locale.getdefaultlocale()?

What is the use case for locale.getdefaultlocale()?

I don't know what the use case is, but this is a public API that's currently broken on macOS. I've run into this issue in the past when using software that uses this API, but to be honest I don't recall which software that was. The BPO issue mentions (older versions of?) docutils that use this API.