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 ezio.melotti, ncoghlan, r.david.murray, vstinner
Date 2015-04-25.07:15:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1429946107.22.0.609504536589.issue23993@psf.upfronthosting.co.za>
In-reply-to
Content
If a Linux distro is using systemd (which is essentially all recent versions of popular distros, including RHEL/CentOS, although it won't land in Ubuntu LTS until 16.04), then cron jobs and service daemons will get their locale set properly based on the contents of /etc/locale.conf. Thus "use an init system that reliably sets the locale correctly for cron jobs and service daemons" is the correct fix for this problem.

Unfortunately, there are still an awful lot of Linux systems out there using other init systems that don't reliably set the locale, and for those "Python 3 shouldn't be worse than Python 2" is a desirable behavioural goal here.

Thus, I think it makes sense for Python to special case the C locale by assuming it's always the wrong setting, and thus surrogateescape is going to be needed on all system interfaces. While it won't be a perfect fix, at least we'll be able to roundtrip data within the system appropriately, even if it still gets corrupted in the face of encoding conversions.
History
Date User Action Args
2015-04-25 07:15:07ncoghlansetrecipients: + ncoghlan, vstinner, ezio.melotti, r.david.murray
2015-04-25 07:15:07ncoghlansetmessageid: <1429946107.22.0.609504536589.issue23993@psf.upfronthosting.co.za>
2015-04-25 07:15:07ncoghlanlinkissue23993 messages
2015-04-25 07:15:05ncoghlancreate