Repository navigation
Introduce fixed point locale aware format type for floating point numbers #79819
Closed as not planned
Description
| BPO | 35638 |
|---|---|
| Nosy | @rhettinger, @mdickinson, @vstinner, @ericvsmith, @skrah, @serhiy-storchaka, @steelman, @huftis |
| PRs |
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 = None
closed_at = None
created_at = <Date 2019-01-02.11:25:01.876>
labels = ['interpreter-core', 'type-feature', '3.9']
title = 'Introduce fixed point locale aware format type for floating point numbers'
updated_at = <Date 2019-09-16.08:15:57.874>
user = 'https://github.com/steelman'bugs.python.org fields:
activity = <Date 2019-09-16.08:15:57.874>
actor = 'vstinner'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2019-01-02.11:25:01.876>
creator = 'steelman'
dependencies = []
files = []
hgrepos = []
issue_num = 35638
keywords = ['patch', 'patch', 'patch', 'patch']
message_count = 18.0
messages = ['332863', '332876', '332877', '332878', '332879', '332880', '332890', '332928', '332930', '332931', '332932', '333000', '333052', '333270', '333296', '333297', '333315', '352492']
nosy_count = 8.0
nosy_names = ['rhettinger', 'mark.dickinson', 'vstinner', 'eric.smith', 'skrah', 'serhiy.storchaka', 'steelman', 'huftis']
pr_nums = ['11405']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue35638'
versions = ['Python 3.9']
Activity
steelman commentedon Jan 2, 2019
It is currently impossible to format floating point numbers with an arbitrary number of decimal digits AND the decimal point matching locale settings. For example no current format allows to display numbers ranging from 1 to 1000 with exactly two decimal digits.
ericvsmith commentedon Jan 2, 2019
Since this is a new feature, it can only be added to 3.8. Adjusting versions accordingly.
I suggest that if we add this at all, it only be added to __format__, not to %-formatting.
Any suggestions on a specification for this?
steelman commentedon Jan 2, 2019
I've got the patch. I will push it to github as soon as I can (some technical issues).
ericvsmith commentedon Jan 2, 2019
Before a patch is created, we should discuss the behavior that will be implemented and agree on it. What is your suggestion?
ericvsmith commentedon Jan 2, 2019
Of course, feel free to create a PR. But the correct place to discuss any new behavior is on the issue tracker, or maybe on python-ideas, not in a PR.
steelman commentedon Jan 2, 2019
I have created a new format "m" that is for "n", what "f" is for "g". The patch for string.rst says
+---------+----------------------------------------------------------+
|
'm'| Number. This is the same as'f', except that it uses || | the current locale setting to insert the appropriate |
| | number separator characters. |
+---------+----------------------------------------------------------+
My patch only applies to floats not integers.
ericvsmith commentedon Jan 2, 2019
I haven't looked at this closely yet, but you'll need to at least:
And, I think we'll need to run this through python-ideas first. One thing I expect to come up there: why f and not g?
Again, I haven't looked through the code yet, or really even given any thought to determining if this is a sound idea.
[-]Introduce fixed point locale awear format type for floating point numbers[/-][+]Introduce fixed point locale aware format type for floating point numbers[/+]4 remaining items
serhiy-storchaka commentedon Jan 4, 2019
You can use locale.format_string() for locale aware formatting.
steelman commentedon Jan 5, 2019
Indeed. Thank you. I was sure I had tried this. However, this is still only a workaround and not the solution I need. I am working on a project now which uses pint https://pint.readthedocs.io/en/latest/ which uses format() and its relatives.
With "n" format present Python is missing locale-aware "f" formatter anyway.
vstinner commentedon Jan 9, 2019
Łukasz Stelmach:
I would like to warn you that handling properly locales can be very tricky. I just wrote an article about that:
https://vstinner.github.io/locale-bugfixes-python3.html
Stefan Krah:
Since it seems like we are still at the "idea" stage, would it make sense to add a function which accept options to choose how to format a number?
Because there are more and more format variants. See for example Python/formatter_unicode.c. It has 5 "locale types":
and it uses this structure:
There is the locale but also "underscore" separator for thousands: see PEP-515.
I'm not talking about adding something into format(), but add a method to float maybe. Or add a function somewhere else.
--
By the way, the decimal module doesn't support properly the following corner case: LC_NUMERIC using an encoding different than LC_CTYPE encoding. I wrote #5191 but I abandonned my change.
skrah commentedon Jan 9, 2019
Maybe, but I think for format() Eric's latest proposal on python-ideas is great ("*f" for "f + LC_NUMERIC", "$f" for "f + LC_MONETARY".
For me that's sufficient. Does locale.format_string() handle the other cases?
Well, I *discovered and opened* bpo-7442 several years ago, and you said:
"I see that various people contributed to the issue, but it looks like the only user asking for the request is Stefan Krah. I prefer to close the issue and wait until more users ask for it before considering again the patch, or find a different way to implement the feature (support LC_NUMERIC and LC_CTYPE locales using a different encoding)."
So why would you think that I'm not aware of that issue? It has low priority for me and I hesitate to depend on the official locale functions in decimal because I don't want to be involved in additional issue reports in that area.
steelman commentedon Jan 9, 2019
I'd appreciate, if we continued the discussion at python-ideas, where I posted the idea[1]. There has already been several valuable comments.
[1] https://mail.python.org/pipermail/python-ideas/2019-January/054793.html
vstinner commentedon Jan 9, 2019
FYI I opened bpo-35697 to discuss the decimal module case.
rhettinger commentedon Sep 15, 2019
I had thought that use a locales were deemed an anti-pattern (not easy-to-use, not thread-safe, etc).
encukou commentedon Sep 2, 2025
The mailing list thread gathered some +1 for a modifier rather than a new type, but then died down.
There is a workaround available:
locale.format_string.At this point, the discussion should be restarted on Discourse if anyone wants to push this forward.
I'll close the issue in a few days if there are no objections.