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.

and

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...

-CHB


--

Christopher Barker, Ph.D.
Oceanographer

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

Chris.Barker@noaa.gov