Repository navigation
locale.nl_langinfo() can't decode THOUSEP monetary value #69998
Description
| BPO | 25812 |
|---|---|
| Nosy | @malemburg, @loewis, @warsaw, @vstinner, @bitdancer, @serhiy-storchaka, @nnja |
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:
assignee = 'https://github.com/nnja'
closed_at = None
created_at = <Date 2015-12-05.21:19:05.273>
labels = ['3.8', 'type-bug', 'library']
title = "locale.nl_langinfo() can't decode value"
updated_at = <Date 2019-01-09.11:53:37.581>
user = 'https://github.com/serhiy-storchaka'bugs.python.org fields:
activity = <Date 2019-01-09.11:53:37.581>
actor = 'vstinner'
assignee = 'nnja'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2015-12-05.21:19:05.273>
creator = 'serhiy.storchaka'
dependencies = []
files = []
hgrepos = []
issue_num = 25812
keywords = []
message_count = 4.0
messages = ['255979', '267017', '267192', '333308']
nosy_count = 7.0
nosy_names = ['lemburg', 'loewis', 'barry', 'vstinner', 'r.david.murray', 'serhiy.storchaka', 'nnja']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue25812'
versions = ['Python 3.8']Linked PRs
Metadata
Metadata
Assignees
Labels
Projects
- Status
Activity
serhiy-storchaka commentedon Dec 5, 2015
Looks as locale.nl_langinfo() always uses the UTF-8 encoding (or may be locale.getpreferredencoding()).
nnja commentedon Jun 3, 2016
Adding the test below to test__locale.py will reproduce the issue under the following conditions:
The locale
uk_UAis installed on your system.'uk_UA': (',', '\xa0') is added to the
known_numericsdictionary in this test file@unittest.skipUnless(nl_langinfo, "nl_langinfo is not available")
def test_lc_numeric_not_char_nl_langinfo(self):
# Test nl_langinfo against known values/
# It should still work if there's a mismatch between
# String & Numeric Locales
tested = False
for loc in candidate_locales:
try:
setlocale(LC_NUMERIC, loc)
except Error:
continue
for li, lc in ((RADIXCHAR, "decimal_point"),
(THOUSEP, "thousands_sep")):
if self.numeric_tester('nl_langinfo', nl_langinfo(li), lc, loc):
tested = True
if not tested:
self.skipTest('no suitable locales')
bitdancer commentedon Jun 4, 2016
Thanks, Nina. We do have support in test.support for running a test with a specific locale (run_with_locale), so this could be turned into a unit test patch if you or someone else is willing to do that.
vstinner commentedon Jan 9, 2019
Since this bug has been reported, locale.localeconv() has been fixed in bpo-31900 to temporarily set LC_CTYPE to LC_NUMERIC to decode numeric fields of localeconv() from the proper encoding. I guess that a similar fix can be applied to locale.nl_langinfo(): set LC_CTYPE to LC_NUMERIC if the parameter is a numeric field.
I only knew locale.nl_langinfo(locale.CODESET). I didn't know that this function accepted other arguments :-)
I even wrote an article about these locale bugs :-)
#5191
See also bpo-35697: "decimal: formatter error if LC_NUMERIC uses a different encoding than LC_CTYPE".
[-]locale.nl_langinfo() can't decode value[/-][+]locale.nl_langinfo() can't decode THOUSEP monetary value[/+]pythongh-69998: Fix decoding error in locale.nl_langinfo()
serhiy-storchaka commentedon Oct 4, 2024
Thank you for suggestion @vstinner. #124963 applies the same solution to
locale.nl_langinfo().gh-69998: Fix decoding error in locale.nl_langinfo() (GH-124963)
serhiy-storchaka commentedon Oct 8, 2024
The changes for
localeconv()were not backported, so this one won't be either.pythongh-69998: Fix decoding error in locale.nl_langinfo() (pythonGH-…