I could reproduce the problem on Fedora Core 5 with Python 2.4.3.
After tracing down the issue, I found the following:
The problem is in locate.py. There is a function called normalize defined in the locate.py file. This function is invoked by setlocale function if the incoming locale argument is not a string. (in your example this condition is true because locale.getlocale function returns a tuple so got variable is a tuple.) The normalize function is using an encoding_alias table which results to translate the full locale into an incorrect version. What happens in my environment is that there is an incoming value en_us.utf-8 which is converted to en_us.utf and that is the return value from normalize function. Then _setlocale low level function invoked in setlocale function throws an exception when it receives en_us.utf argument and it is an unsupported locale setting.
This is the original code snippet in locale.py where it is converted in a wrong way in normalize function:
# Second try: langname (without encoding)
code = locale_alias.get(langname, None)
if code is not None:
if '.' in code:
langname, defenc = code.split('.')
else:
langname = code
defenc = ''
if encoding:
encoding = encoding_alias.get(encoding, encoding)
else:
encoding = defenc
if encoding:
return langname + '.' + encoding
else:
return langname
else:
return localename
To get it fixed, I modified the code in locate.py as follows:
# Second try: langname (without encoding)
code = locale_alias.get(langname, None)
if code is not None:
if '.' in code:
langname, defenc = code.split('.')
else:
langname = code
defenc = ''
# if encoding:
# encoding = encoding_alias.get(encoding, encoding)
# else:
# encoding = defenc
if encoding is None:
encoding = defenc
if encoding:
return langname + '.' + encoding
else:
return langname
else:
return localename
So the effect of encoding_table is skipped. Then your test_locale.py returns OK.