There was a bunch of discussion about all this a while back, in which I think these points were addressed:

However, in some cases the C locale is a normal environment for system services, cron scripts, distro package builds and whatnot.

Indeed it is. But:

if you run a Python (or any) program that is expecting an ASCII-only locale, then it will work jsut fine with any ascii-compatible locale. -- so no problem there.

On the other hand, if you run a program that is expectign a unicode-aware locale, then it might barf unexpectently if run on a ASCII-only locale. A lot of people do in fiact have these issues (which are due to mis-configuration of the host system, which is indeed not properly Python's problem).
So if we do all this, then:

A) mis-configured systems will magically work (sometimes)

 This is a Good Thing.


B) If someone runs a python program that is expecting Unicode support on an properly configured ASCII-only system, then it will mostly "just work" -- after all a lot of C APIs are simply char*, who cares what the encoding is? It would not, however, fail if when a non-ascii value is used somewhere it shouldn't. 

So the question nis -- is anyone counting on errors in this case? i.e., is a sysadmin thinking:

"I want an ASCII-only system, so I'll set the locale, and now I can expect any program running on this system that is not ascii compatible to fail."

I honestly don't know if this is common -- but I would argue that trying to run a unicode-aware program on an ASCII-only system could be considered a mis-configuration as well.

Also -- many programs will just be writing bytes to the system without checking encoding anyway. So this would simply let Python3 programs behave like most others...



Christopher Barker, Ph.D.

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception