homepage

> Maybe we should return TypeError with the same message then? That
> would require some modification of documentation though, as it
> states: "If the modification of the locale fails, the exception Error
> is raised.".
No, any operation can report TypeError and ValueError without explicit
mentioning in the documentation. Saying that the parameters should be
this and that implies that if they are different, you get a TypeError
or ValueError.
> I don't really understand the "locale unpacking may actually
> succeed". Isn't that what supposed to happen, to my knowledge "en" is
> not a valid locale and that's a totally different issue?
See my example again:
py> locale.setlocale(locale.LC_ALL,u"en")
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/usr/lib/python2.6/locale.py", line 513, in setlocale
 return _setlocale(category, locale)
locale.Error: unsupported locale setting
py> locale.setlocale(locale.LC_ALL,u"eng")
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/usr/lib/python2.6/locale.py", line 512, in setlocale
 locale = normalize(_build_localename(locale))
 File "/usr/lib/python2.6/locale.py", line 420, in _build_localename
 language, encoding = localetuple
ValueError: too many values to unpack
So for u"eng" you get the ValueError. For u"en", you get past that
point, and then get a locale.Error. These are both Unicode strings,
but the outcome is quite different (and still would be different
under your patch).