This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients ezio.melotti, lemburg, loewis, skrah, terry.reedy, vincent.chute
Date 2011-06-18.23:28:30
SpamBayes Score 0.0
Marked as misclassified No
Message-id <1308439711.38.0.782341808596.issue3067@psf.upfronthosting.co.za>
In-reply-to
Content
After more thought and investigation, I have changed my opinions on this issue.


Allowing unicode string for locale in 2.7:
Since the module predates unicode strings (it is in 1.5) and since the locale string is passed to a C function, 'string' in the doc can just as well be taken to mean ascii byte string only, as the code requires. As far as I know, unicode is never needed. Allowing such could be considered a feature addition, which is not allowed for 2.7. So I would reject the OP's request (and have hence changed the title).

Expected failure cases could be added to test_locale.py.


Options for locale name:
As I remember, multiple assignments in 1.5, as in

def _build_localename(localetuple):
    language, encoding = localetuple

required a tuple on the right and was called 'tuple unpacking'.
Now, any iterable producing 2 items works; Rather than change to code to check that 'localetuple' really is a tuple (which could break code and the principle of duck-typing), I think the doc should be updated to

"If locale is specified, it may be a None, a string, or an iterable producing two strings, language code and encoding."

This is not a feature addition but a recognition of a new feature added versions ago. The parameter name in the private function should then be shortened to just 'locale'.

Test cases with non-tuples could be added if not present now.


Exception message:
The current message arises from setlocale assuming that a 'locale' that is neither None or a string is a valid iterable for a call to _build_localename. A strings of the wrong type produces too many items and hence the obscure message.

Python is known to be inconsistent in its usage of ValueError versus TypeError for builtin function args. Guido has said to leave inconsistencies rather than break code. So I retract the ValueError to TypeError suggestion.

The accompanying messages, however, can be improved. The lines above that fails could be wrapped with
    try:
        language, encoding = locale
    except ValueError:
        raise ValueError("Locale must be None, a string, or an iterable of two strings -- language code, encoding -- not {}".format(locale))

The scope of the wrapper could be extended to the entire function so that failure of
        return language + '.' + encoding
would also be caught. Failure would happen if locale produced 2 non-strings items, so that the double assignment 'worked', but the string concatenation failed.

A complication: the doc says
"exception locale.Error 
Exception raised when setlocale() fails.

locale.setlocale(category, locale=None) 
...If the modification of the locale fails, the exception Error is raised."

So it seems that either a) the wrapper above should raise Error instead, or the doc could more clearly say "Exception raised when the locale passed to setlocale is not recognized."
History
Date User Action Args
2011-06-18 23:28:31terry.reedysetrecipients: + terry.reedy, lemburg, loewis, ezio.melotti, vincent.chute, skrah
2011-06-18 23:28:31terry.reedysetmessageid: <1308439711.38.0.782341808596.issue3067@psf.upfronthosting.co.za>
2011-06-18 23:28:30terry.reedylinkissue3067 messages
2011-06-18 23:28:30terry.reedycreate