Author loewis
Recipients eric.araujo, ezio.melotti, lemburg, loewis, nailor, python-dev, skrah, terry.reedy, vincent.chute, vstinner
Date 2011-10-18.19:30:37
SpamBayes Score 2.64166e-09
Marked as misclassified No
Message-id <>
In-reply-to <>
> 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/", 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/", line 512, in setlocale
    locale = normalize(_build_localename(locale))
  File "/usr/lib/python2.6/", 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).
Date User Action Args
2011-10-18 19:30:38loewissetrecipients: + loewis, lemburg, terry.reedy, vstinner, ezio.melotti, eric.araujo, vincent.chute, skrah, nailor, python-dev
2011-10-18 19:30:37loewislinkissue3067 messages
2011-10-18 19:30:37loewiscreate