This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients ezio.melotti, ncoghlan, r.david.murray, vstinner
Date 2015-04-18.15:00:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> I am -1 on this.  (Or may be more).  What's the rationale?

See the issue #19977.

In many cases you get the C locale by mistake. For example, by setting the LANG environment variable to an empty string to run a program in english (whereas LC_MESSAGES is the appropriate variable).

For deamons, in many cases you get the C locale and it's hard to configure all systems to run the daemon with the user locale. I read that systemd runs daemons with the user locale, but I'm not sure.

The idea is to reduce the pain caused by this locale. When porting an application from Python 2 to Python 3, it's annoying to start to get unicode errors everywhere. This issue starts to make Python 3 more convinient.

> I could see using utf-8 by default if the locale is C,

This has been proposed many times, but I'm opposed to that. Python must be interoperable with other programs, and other programs use the locale encoding. For example, you get the ASCII locale encoding when the LC_CTYPE is the POSIX locale ("C"). If Python writes UTF-8, other applications will be unable to decode UTF-8 data.

Maybe I'm wrong and you should continue to investigate this option.

This issue is very specific to "OS" data: environment variables, filenames, command line arguments, standard streams (stdin, stdout, stderr). You may do other choices for other kind of data unrelated to the locale encoding. For example, JSON must use UTF-8, it's well defined. XML announces its encoding. etc.
Date User Action Args
2015-04-18 15:00:04vstinnersetrecipients: + vstinner, ncoghlan, ezio.melotti, r.david.murray
2015-04-18 15:00:04vstinnersetmessageid: <>
2015-04-18 15:00:04vstinnerlinkissue23993 messages
2015-04-18 15:00:03vstinnercreate