[issue1443504] locale.getpreferredencoding() dies when setlocale fails

Jeroen Ruigrok van der Werven report at bugs.python.org
Thu Apr 30 22:22:22 CEST 2009


Jeroen Ruigrok van der Werven <asmodai at 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 <report at bugs.python.org>
<http://bugs.python.org/issue1443504>
_______________________________________


More information about the Python-bugs-list mailing list