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 Dmitry.Jemerov, Ilya.Kulakov, alexander.sturm, barry-scott, karolyi, larryv, loewis, ncoghlan, ned.deily, r.david.murray, ronaldoussoren, serhiy.storchaka, tsparber, vstinner, wolma
Date 2017-01-12.12:59:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1484225966.43.0.0898306542676.issue18378@psf.upfronthosting.co.za>
In-reply-to
Content
PEP 538 wouldn't help here, as there's nothing wrong with CPython's assumptions about the text encoding to use for operating system interfaces - it's assuming UTF-8 (because it's Mac OS X) and that assumption is correct (because it's Mac OS X).

The problem appears to be that locale.py was written primarily for Linux, and hence makes assumptions that aren't valid on BSD and Mac OS X.

Dmitry's suggested solution of taking the BSD/Mac OS X specific locale of "UTF-8" and universally accepting it as meaning (None, "UTF-8") sems like a sensible step forward, even if it doesn't resolve all the discrepancies.

Where PEP 538 and PEP 540 would come into play is when this setting gets forwarded over SSH to Linux servers (as then CPython *will* get the nominal system text encoding wrong), but that's independent of getting the locale module to handle it more gracefully.
History
Date User Action Args
2017-01-12 12:59:26ncoghlansetrecipients: + ncoghlan, loewis, barry-scott, ronaldoussoren, vstinner, ned.deily, r.david.murray, Dmitry.Jemerov, larryv, serhiy.storchaka, wolma, Ilya.Kulakov, tsparber, karolyi, alexander.sturm
2017-01-12 12:59:26ncoghlansetmessageid: <1484225966.43.0.0898306542676.issue18378@psf.upfronthosting.co.za>
2017-01-12 12:59:26ncoghlanlinkissue18378 messages
2017-01-12 12:59:26ncoghlancreate