Author ncoghlan
Recipients Sworddragon, a.badger, bkabrda, larry, lemburg, loewis, ncoghlan, pitrou, r.david.murray, serhiy.storchaka, terry.reedy, vstinner
Date 2013-12-09.01:54:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1386554066.53.0.779178662607.issue19846@psf.upfronthosting.co.za>
In-reply-to
Content
End users tripping over this by setting LANG=C is one of the pain points of Python 3 relative to Python 2 for Fedora, so I've added a couple of Fedora folks to the nosy list.

My current understanding of the situation:

- we should leave Windows and Mac OS X alone, since they ignore the locale when choosing the OS API encoding anyway

- the main problem is on Linux (but potentially other *nix systems as well), where people set "LANG=C" for a variety of reasons, but this has the side effect of Python 3 choosing an inappropriate encoding (ASCII rather than UTF-8) when talking to the OS APIs.

Given the initialisation problems, this may be something that PEP 432 (the initialisation process rewrite) can help with (since it changes the initialisation order to create a more complete Python runtime before it starts to configure the OS interfaces).

Tangentially related, we may want to consider aliasing sys.getfilesystemencoding, os.fsencode and os.fsdecode as something like sys.getosapiencoding, os.apiencode and os.apidecode, since the current naming is misleading (the value is based on the platform and environment, not any particular filesystem, and is used for almost all bytes-based OS APIs, not just filesystem metadata)
History
Date User Action Args
2013-12-09 01:54:26ncoghlansetrecipients: + ncoghlan, lemburg, loewis, terry.reedy, pitrou, vstinner, larry, a.badger, r.david.murray, Sworddragon, serhiy.storchaka, bkabrda
2013-12-09 01:54:26ncoghlansetmessageid: <1386554066.53.0.779178662607.issue19846@psf.upfronthosting.co.za>
2013-12-09 01:54:26ncoghlanlinkissue19846 messages
2013-12-09 01:54:25ncoghlancreate