Message205564
| Author |
ncoghlan |
| Recipients |
deleted250130, larry, lemburg, loewis, ncoghlan, pitrou, r.david.murray, serhiy.storchaka, terry.reedy, vstinner |
| Date |
2013年12月08日.14:09:48 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<CADiSq7e6ezh+WhioX48CXWCtaEYCXomj865S_uY_tjJT9Q9hpA@mail.gmail.com> |
| In-reply-to |
<1386506295.29.0.271334200978.issue19846@psf.upfronthosting.co.za> |
| Content |
Victor, people set "LANG=C" for all sorts of reasons, and we have no
control over how operating systems define that locale. The user
perception is "Python 3 doesn't work properly when you ssh into
systems", not "Gee, I wish operating systems defined the C locale more
sensibly".
If you can come up with a more sensible guess than UTF-8, great, but
believing the nonsense claim of "ASCII" from the OS is a
not-insignificant usability issue on Linux, because it hoses *all* the
OS API interactions. Yes, theoretically, using UTF-8 can cause
problems, *if* the following all occur:
- the OS *claims* the OS encoding is ASCII (so Python uses UTF-8 instead)
- the OS encoding is *actually* something other than UTF-8
- the program encounters non-ASCII data and writes it out to disk
For fear of doing the wrong thing in that incredibly rare scenario,
you're leaving Python broken under the C locale on *every* modern
Linux distro as soon as it encounters non-ASCII data in an OS
interface. |
|