clone 579324 -1 -2 reassign -1 python2.5 2.5.5-6 retitle -1 python2.5: does not uppercase "i" correctly in tr_TR.utf8 locale reassign -2 python2.6 2.6.5-1 retitle -2 python2.6: does not uppercase "i" correctly in tr_TR.utf8 locale reassign 579324 reportbug 4.12.1 retitle 579324 reportbug: doesn't cope with tr_TR locales thanks
* Sandro Tosi <mo...@debian.org>, 2010-04-27, 07:30:
reassign 579324 python2.5 python2.6 thanks
A bug should be assigned to two packages if it can be fixed in either of them. This is not the case here, so I took the liberty to clone and reassign this bug.
There's something weird going on here: I'm able to replicate this problem with LANG=tr_TR.UTF-8 but the problem is inside python. The code that is executed is: MODELIST = ['novice', 'standard', 'advanced', 'expert'] for mode in MODELIST: exec 'MODE_%s=%d' % (mode.upper(), MODELIST.index(mode)) del mode
Please bear in mind that: - str.upper() is locale-dependent;- In Turkish locales, uppercase version of "i" (LATIN SMALL LETTER I) is "İ" (LATIN CAPITAL LETTER I WITH DOT ABOVE).
Python obviously fails to capitalize "i" in tr_TR.utf8 locale (presumably because it internally uses C language toupper(), which cannot deal with multi-byte sequences).
However, even if Python did capitalization correctly, reportbug's code would still trigger an exception. (That's why I reassigned one of copies of the bug back to reportbug.)
The solution to the reportbug's part of the problem is easy: *never* change locale; the C locale subsystem is just to fragile to use it in a sane way. Changing locale should be rarely needed anyway:
- You can get the preferred encoding with locale.getpreferredencoding(). - gettext translations works fine without setting locale (IIRC). A related bug: http://bugs.python.org/issue1813 -- Jakub Wilk
signature.asc
Description: Digital signature
