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 debian-python-REQUESTlists.debian.org
with a subject of "unsubscribe". Trouble?
Contact listmasterlists.debian.org
|