homepage

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.