Author ncoghlan
Recipients Jan Niklas Hasse, Sworddragon, abarry, akira, barry, ezio.melotti, inada.naoki, lemburg, ncoghlan, r.david.murray, vstinner, yan12125
Date 2017-01-05.10:50:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1483613428.37.0.466599990107.issue28180@psf.upfronthosting.co.za>
In-reply-to
Content
No, requesting a locale that doesn't exist doesn't error out, because we don't check the return code - it just keeps working the same way it does now (i.e. falling back to the legacy C locale).

However, it would be entirely reasonable to put together a competing PEP proposing to eliminate the reliance on the problematic libc APIs, and instead use locale independent replacements. I'm simply not offering to implement or champion such a PEP myself, as I think ignoring the locale settings rather than coercing them to something more sensible will break integration with C/C++ GUI toolkits like Tcl/Tk, Gtk, and Qt, and it's reasonable for us to expect OS providers to offer at least one of C.UTF-8 or en_US.UTF-8 (see https://github.com/python/peps/issues/171 for more on that).
History
Date User Action Args
2017-01-05 10:50:28ncoghlansetrecipients: + ncoghlan, lemburg, barry, vstinner, ezio.melotti, r.david.murray, inada.naoki, akira, Sworddragon, yan12125, abarry, Jan Niklas Hasse
2017-01-05 10:50:28ncoghlansetmessageid: <1483613428.37.0.466599990107.issue28180@psf.upfronthosting.co.za>
2017-01-05 10:50:28ncoghlanlinkissue28180 messages
2017-01-05 10:50:28ncoghlancreate