homepage

[forwarded from http://bugs.debian.org/185776]
$ LC_ALL=en_ZA python
Python 2.3.1 (#2, Sep 24 2003, 11:39:14) 
[GCC 3.3.2 20030908 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> locale.getdefaultlocale()
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "/usr/lib/python2.3/locale.py", line 346, in
getdefaultlocale
 return _parse_localename(localename)
 File "/usr/lib/python2.3/locale.py", line 280, in
_parse_localename
 raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: en_ZA
Note that locale.getlocale correctly returns (None, None)
locale.getdefaultlocale() calls _parse_localename,
which throws a ValueError if normalize e.g. does not
return an encoding.
If this behaviour in python is "as it should be",
locale.getdefaultlocale should document it as such, to
make it clear to apps using getdefaultlocale that they
*must indeed* handle such an exception gracefully. (In
this case, it could probably be a "normal" bug, then
the "important" bug belongs with apt-listchanges.)
The problem might be (depending on "specifications")
either getlocale returning ValueError in the "unknown"
case, or it could be because locale_alias does not
contain an entry for en_ZA...

Logged In: YES 
user_id=21627
This is a known limitation: getdefaultlocale should not be
used in new code.
If the intention is to compute the locale's encoding,
locale.getpreferredencoding should be used instead.

Logged In: YES 
user_id=469548
http://python.org/sf/504219 seems to be the same bug.

Logged In: YES 
user_id=849994
Closing as duplicate of #504219.