New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
locale.setlocale does not work with unicode strings #69928
Comments
Within locale.py in setlocale your have this piece of code: if locale and type(locale) is not type(""):
# convert to string
locale = normalize(_build_localename(locale)) That does not work with unicode strings as I found out after wondering quite a bit about the difference was between my tests and my production code... So either expand the check here to include type(u"") or make _build_localename smarter. |
The doc for setlocale(category [,locale]) says "locale may be a string, or an iterable of two strings (language code and encoding)". The purpose of _build_locale is handle an iterable of two strings. This request looks like an enhancement request, which is not allowed for 2.7. I suspect that the locale locale module and doc predate the addition of unicode. I think this should be closed. |
I wouldn't say this is a feature request. What the code wanted to check is "if this is an iterable of two strings, convert these to a locale string". I have no idea why the doc string uses "iterable". IMO, a tuple of two strings would have been fine and make the test case a lot simpler - too late to fix, though. If the code works with Unicode strings, I think we can change the test to: if locale and not isinstance(locale, basestring):
... In Python 3, the function will only accept Unicode strings, so no need to fix things there. @Tierlieb: Could you provide a patch with test for this ? Thanks. |
I don't see the benefit of supporting Unicode strings for setlocale() arguments: locale name are always encodable to ASCII, so loc.decode('ascii') is enough to workaround the issue. But well, I think it's ok if it doesn't make the code much more complex ;-) I wrote a patch, what do you think? Is it worth it? ;-) |
On 27.11.2015 23:11, STINNER Victor wrote:
Thanks :-)
I think so, since the current failure for Unicode is rather BTW: Why did you use (_str, _unicode) instead of basestring ? |
Serhiy usually insists that technically, it's possible to compile Python 2.7 without Unicode support. I don't believe that anyone uses this crazy feature, but well, it was easier to use _unicode (which is already defined) than trying to run a poll on python users :-) |
New changeset 7841e9b614eb by Victor Stinner in branch '2.7': |
On 27.11.2015 23:50, STINNER Victor wrote:
Hmm, but basestring is always defined, even when Python is compiled |
Marc-Andre Lemburg added the comment:
Oh, I didn't know. Well, I already pushed my patch and it works. Feel Thanks for the review.by the way. |
On 28.11.2015 00:00, STINNER Victor wrote:
No big deal. There are probably lots more places in the stdlib which
Thanks for the patch. |
Marc-Andre Lemburg added the comment:
Well, to have more fun, try to run any Python application with a |
http://buildbot.python.org/all/builders/x86%20XP-4%202.7/builds/3517/steps/test/logs/stdio Traceback (most recent call last):
File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\test\test_locale.py", line 497, in test_setlocale_unicode
old_loc = locale.getlocale(locale.LC_ALL)
File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\locale.py", line 565, in getlocale
raise TypeError, 'category LC_ALL is not supported'
TypeError: category LC_ALL is not supported |
New changeset d7481ebeaa4f by Victor Stinner in branch '2.7': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: