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 ncoghlan
Recipients Sworddragon, 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.
History
Date User Action Args
2013-12-08 14:09:48ncoghlansetrecipients: + ncoghlan, lemburg, loewis, terry.reedy, pitrou, vstinner, larry, r.david.murray, Sworddragon, serhiy.storchaka
2013-12-08 14:09:48ncoghlanlinkissue19846 messages
2013-12-08 14:09:48ncoghlancreate