N.B. I'm sorry if you got this email twice... I mixed up an email on my
1st trial... need sleep... please reply to this one instead so all
relevant entities get "in the loop"
I think that this old bug (185776) is related to fresh #372684 and
#369689 (which I reassigned to python2.3)
Following code snippet having locale en_DK installed leads to the
"desired" behavior (the same was shown in #369689)
> cat ./test_locale.py
#!/usr/bin/python2.3
import locale
import time
print `locale.setlocale(locale.LC_ALL,'')`
print time.strptime('May 31 09:30:01', '%b %d %H:%M:%S')
*> LC_ALL=en_DK python2.3 ./test_locale.py
'en_DK'
Traceback (most recent call last):
File "./test_locale.py", line 8, in ?
print time.strptime('May 31 09:30:01', '%b %d %H:%M:%S')
File "/usr/lib/python2.3/_strptime.py", line 402, in ?
_locale_cache = TimeRE()
File "/usr/lib/python2.3/_strptime.py", line 318, in __init__
self.locale_time = LocaleTime()
File "/usr/lib/python2.3/_strptime.py", line 106, in __init__
self.__lang = _getlang()
File "/usr/lib/python2.3/_strptime.py", line 31, in _getlang
return locale.getlocale(locale.LC_TIME)
File "/usr/lib/python2.3/locale.py", line 365, in getlocale
return _parse_localename(localename)
File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename
raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: en_DK
Interesting enough it is in the same state for python 2.4 and 2.5 but
works fine for 2.2 (probably due to the fact that there were not
fancy locale handling at all, and strptime was merely a wrapper to libc
functions):
*> LC_ALL=en_DK python2.2 ./test_locale.py
'en_DK'
(1900, 5, 31, 9, 30, 1, 3, 151, 0)
Having closer look at how locale deals with locales (and disregarding
all shortcuts for this bug discussion ;-)), I found that it
depends on hardcoded list of locales in locale_alias and neither en_DK
nor many other (eg ru_UA) are in that list. That causes locale.normalize
function to do nothing on those, thus providing function
_parse_localename with no '.' in the normalized name (ie without split
into language.encoding which at the end causes _parse_localename to
throw an exception. No comment to locale_alias about missing locales
was detected. only for windows_locale there was:
# NOTE: this mapping is incomplete. If your language is missing, please
# submit a bug report to Python bug manager, which you can find via:
# http://www.python.org/dev/
# Make sure you include the missing language identifier and the suggested
# locale code.
So my guess to fix all those bugs in fast way, missing locales
should be added to the list. It seems, although en_ZA was found
missing,it wasn't added and still missing for locale_alias, thus
showing that this solution might be highly ineffective and wrong way.
Better way to fix this would be probably to add use of
/usr/share/i18n/SUPPORTED which has all those lang.encoding aliases
defined. That also would favor more orthogonal design, so that python's
internals don't duplicate (and thus ommit) some locales defined on the
system. /usr/share/i18n/SUPPORTED is highly Linux specific solution thus
might not be favored by python upstream, but might be very crucial for
i18n support of python among debian community.
P.S. Please CC me replies from the list since I'm not subscribed to d-p
--
.-.
=------------------------------ /v\ ----------------------------=
Keep in touch // \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User ^^-^^ [175555]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
