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 asmodai
Recipients asmodai, catherinedevlin, heikki, jminka
Date 2009-04-30.20:22:20
SpamBayes Score 0.0
Marked as misclassified No
Message-id <>
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 is not adhering to the
standard by not allowing the "" case properly. _parse_localename() is
being overly pedantic about this by raising a ValueError.
Date User Action Args
2009-04-30 20:22:22asmodaisetrecipients: + asmodai, catherinedevlin, jminka, heikki
2009-04-30 20:22:22asmodaisetmessageid: <>
2009-04-30 20:22:20asmodailinkissue1443504 messages
2009-04-30 20:22:20asmodaicreate