python / cpython

The Python programming language
https://www.python.org
Other
62.36k stars 29.95k forks source link

German number separators not working using format language and locale "de_DE" #61148

Closed ab9a16a9-9eca-4f4e-8aeb-ee00833f4535 closed 11 years ago

ab9a16a9-9eca-4f4e-8aeb-ee00833f4535 commented 11 years ago
BPO 16944
Nosy @mdickinson, @ericvsmith, @skrah

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: ```python assignee = None closed_at = created_at = labels = ['invalid', 'type-bug', 'library'] title = 'German number separators not working using format language and locale "de_DE"' updated_at = user = 'https://bugs.python.org/PeterStahl' ``` bugs.python.org fields: ```python activity = actor = 'skrah' assignee = 'none' closed = True closed_date = closer = 'skrah' components = ['Library (Lib)'] creation = creator = 'Peter.Stahl' dependencies = [] files = [] hgrepos = [] issue_num = 16944 keywords = [] message_count = 6.0 messages = ['179785', '179787', '179788', '179789', '179951', '179953'] nosy_count = 4.0 nosy_names = ['mark.dickinson', 'eric.smith', 'skrah', 'Peter.Stahl'] pr_nums = [] priority = 'normal' resolution = 'not a bug' stage = 'resolved' status = 'closed' superseder = None type = 'behavior' url = 'https://bugs.python.org/issue16944' versions = ['Python 2.6', 'Python 3.1', 'Python 2.7', 'Python 3.2', 'Python 3.3'] ```

ab9a16a9-9eca-4f4e-8aeb-ee00833f4535 commented 11 years ago

Yesterday, I opened a question on Stackoverflow that explains my problem in detail. Please read this page first:

http://stackoverflow.com/questions/14287051/german-number-separators-using-format-language-on-osx

A short summary: I'm on OSX 10.8.2. I wanted to format numbers according to the German numbering convention using Python's format language and the locale setting "de_DE". Actually, the following should work to achieve that:

>> import locale >> locale.setlocale(locale.LC_ALL, 'de_DE') >> '{0:n}'.format(1234.56)

The result of the last expressions should be 1.234,56. However, my result is 1234,56. More examples are on Stackoverflow.

According to what other SO members have found out, this is a problem with the locale settings of OSX because the grouping of numbers is not fully part of the locale "de_DE". On Windows, however, grouping works fine using the locale "deu_deu" which is not available on OSX.

Is this a bug? At least, it doesn't seem to be documented anywhere and is probably not the correct behavior even on OSX. Others have reported similar problems on OSX as well.

Do you have a quick solution for this issue? Thanks in advance.

5531d0d8-2a9c-46ba-8b8b-ef76132a492c commented 11 years ago

What is the output of this?

>>> locale.localeconv()                     
{'mon_decimal_point': ',', 'frac_digits': 2, 'p_sign_posn': 1, 'thousands_sep': '.', 'p_sep_by_space': 1, 'int_curr_symbol': 'EUR ', 'decimal_point': ',', 'mon_thousands_sep': '.', 'n_sep_by_space': 1, 'int_frac_digits': 2, 'currency_symbol': 'EUR', 'negative_sign': '-', 'mon_grouping': [3, 3, 0], 'positive_sign': '', 'n_cs_precedes': 0, 'grouping': [3, 3, 0], 'n_sign_posn': 1, 'p_cs_precedes': 0}

If 'grouping' is [], then this looks like a bug in OSX. Python gets the values directly from the operating system.

ab9a16a9-9eca-4f4e-8aeb-ee00833f4535 commented 11 years ago

Using the locale 'de_DE', the output is:

{'mon_decimal_point': ',', 'int_frac_digits': 2, 'p_sep_by_space': 0, 'frac_digits': 2, 'thousands_sep': '', 'n_sign_posn': 1, 'decimal_point': ',', 'int_curr_symbol': 'EUR ', 'n_cs_precedes': 1, 'p_sign_posn': 1, 'mon_thousands_sep': '.', 'negative_sign': '-', 'currency_symbol': 'Eu', 'n_sep_by_space': 0, 'mon_grouping': [3, 3, 0], 'p_cs_precedes': 1, 'positive_sign': '', 'grouping': [127]}

What does the number 127 mean?

Am 12.01.2013 um 12:39 schrieb Stefan Krah \report@bugs.python.org\:

Stefan Krah added the comment:

What is the output of this?

>>> locale.localeconv()
{'mon_decimal_point': ',', 'frac_digits': 2, 'p_sign_posn': 1, 'thousands_sep': '.', 'p_sep_by_space': 1, 'int_curr_symbol': 'EUR ', 'decimal_point': ',', 'mon_thousands_sep': '.', 'n_sep_by_space': 1, 'int_frac_digits': 2, 'currency_symbol': 'EUR', 'negative_sign': '-', 'mon_grouping': [3, 3, 0], 'positive_sign': '', 'n_cs_precedes': 0, 'grouping': [3, 3, 0], 'n_sign_posn': 1, 'p_cs_precedes': 0}

If 'grouping' is [], then this looks like a bug in OSX. Python gets the values directly from the operating system.

---------- nosy: +skrah status: open -> pending


Python tracker \report@bugs.python.org\ \http://bugs.python.org/issue16944\


5531d0d8-2a9c-46ba-8b8b-ef76132a492c commented 11 years ago

127 means "no-more-grouping", so Python behaves as instructed by the OS.

As you see, the OS prescribes 1.345.677,222 for *monetary* quantities and 1345677,222 otherwise.

According to http://de.wikipedia.org/wiki/DIN_1333 , for non monetary quantities DIN-1333 says *empty spaces *may be used as separators. DIN-5008 says they *should* be used. :)

Most operating systems use [3, 3, 0] also for de_DE 'grouping', but given the unclear situation it's hard to claim a bug in OSX.

The only way out of this would be to introduce a new 'm' locale specifier that uses mon_grouping.

ericvsmith commented 11 years ago

I think this issue should be closed, since we're doing as we're instructed by the OS. If someone wants to open a new issue for the "m" format specifier type, I'd support that.

5531d0d8-2a9c-46ba-8b8b-ef76132a492c commented 11 years ago

I agree, we can't really do anything here.