Jeroen Ruigrok van der Werven <asmo...@in-nomine.org> added the comment:
You don't want to completely nix the setlocale(LC_CTYPE, "") call though. The "" denotes to grab the native environment, in other words, to grab whatever the current user's LC_CTYPE environment variable is set to (see `locale -a`) and then set the program's LC_CTYPE to that. Of course, this might be set to something that might be valid (e.g. cy_GB.ISO8859-15), but has no matching entry in /usr/share/locale (or wherever your system provides it) and as such it fails. Reading SUS (The Single Unix Specification) I see that it explicitly says: "Upon successful completion, setlocale() shall return the string associated with the specified category for the new locale. Otherwise, setlocale() shall return a null pointer and the locale of the process is not changed." So the patch seems to be correct actually. We try to setlocale(LC_CTYPE, "") to grab a locale from the environment to set LC_CTYPE, but we fail for whatever, so we should just pass since we should not adjust LC_CTYPE. Mmm, but it seems setlocale() in locale.py is not adhering to the standard by not allowing the "" case properly. _parse_localename() is being overly pedantic about this by raising a ValueError. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1443504> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
