Some values in the dict returned by localeconv() may be non-ASCII
strings, yet they are not decoded according to the locale's character
set. This can be observed when the currency symbol is the euro sign:

>>> import locale
>>> locale.setlocale(locale.LC_MONETARY, 'fr_FR.UTF-8')
'fr_FR.UTF-8'
>>> locale.localeconv()['currency_symbol']
'\xe2\x82\xac'
>>> locale.setlocale(locale.LC_MONETARY, 'fr_FR.ISO8859-15')
'fr_FR.ISO8859-15'
>>> locale.localeconv()['currency_symbol']
'\xa4'

localeconv() is defined in the _locale module, which has no knowledge of
the current encoding - but the locale module does. So we could redefine
localeconv() in locale as a wrapper, to do the proper encoding dance.

Here is a patch fixing the problem. Note however that it will make
localeconv() quite slower. Perhaps _locale.localeconv should grow an
encoding parameter instead.

The locale module is completely broken; don't try to work around that
breakage. One option would be to remove it entirely.

Perhaps it is broken - it does look rather fragile - but are there any
plans to design a replacement?

Perhaps it is broken - it does look rather fragile - but are there any
plans to design a replacement?

If people could contribute an ICU wrapper - that would be nice. However,
it's unlikely to happen. So I'll rather rewrite _locale to use wchar_t
functions, and give up on systems where these are not available, or
where wchar_t is not Unicode (not sure how to detect the latter case).

I found now a way to fix this, by relying on wchar_t functions. It's
fixed in r61306