string formatting that produces floats with preset precision while respecting locale

[JakubSzewczyk]

BPO	33731
Nosy	@rhettinger, @ericvsmith, @cedk, @skrah, @james-emerton
PRs	bpo-33731: Implement support for locale specific format (WIP) #8612

^{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/ericvsmith'
closed_at = None
created_at = <Date 2018-06-01.12:42:33.231>
labels = ['interpreter-core', 'type-feature', '3.8']
title = 'string formatting that produces floats with preset precision while respecting locale'
updated_at = <Date 2019-08-14.11:34:15.211>
user = 'https://bugs.python.org/JakubSzewczyk'

bugs.python.org fields:

activity = <Date 2019-08-14.11:34:15.211>
actor = 'ced'
assignee = 'eric.smith'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2018-06-01.12:42:33.231>
creator = 'Jakub Szewczyk'
dependencies = []
files = []
hgrepos = []
issue_num = 33731
keywords = ['patch']
message_count = 6.0
messages = ['318407', '318410', '322911', '322913', '322914', '349684']
nosy_count = 6.0
nosy_names = ['rhettinger', 'eric.smith', 'ced', 'skrah', 'jemerton', 'Jakub Szewczyk']
pr_nums = ['8612']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue33731'
versions = ['Python 3.8']

[JakubSzewczyk]

.2f produces a string representation of a float rounded up to 2 significant digits.

>>> print ("{:.2f}".format(1.891))
1.89

However, it does not respect locale. There is no counterpart of 'f' that would respect locale. There is 'n', but because it follows the rules of 'g', in many cases it returns a different number of significant digits.

>>> print ("{:.2n}".format(1.891))
1.9

In all my uses of formatted float printing, I need to produce floats that are rounded to have the same number of significant digits. I _presume_ this generalizes to the majority people, and the use of 'f' option is much more widespread than the use of 'g'. If this is the case, then a locale-friendly counterpart of 'f' would be very useful.

[ericvsmith]

You can always use the locale module, although of course that's not as convenient:

>>> locale.format('%.2f', 1.891)
'1.89'

I'm open to suggests on backward compatible ways to implement this for python 3.8. It would probably involve a new letter, and need to be implemented for at least int, float, decimal, and complex.

[james-emerton]

So far, I've implemented this for Decimal

[rhettinger]

I would like to see locale() remain somewhat decoupled from the rest of string formatting. IIRC locale() is finicky especially when concurrency is involved. I think a best practice is for an app to address locale issues explicitly rather than inside string formatting. I'll defer to those with more experience using locale -- I just have a vague recollection of this being an area fraught with landmines.

[james-emerton]

@rhettinger See bpo-34311 about formatting Decimals using locale.format(). I'd like to see the problem fixed in one place or the other.

Also, this is seems relatively straightforward to implement as it's really just a combination of the fixed precision 'f' and the locale specific 'n' format types.

[cedk]

I think PR-15275 will solves this issue also as you could use:

>>> locale.setlocale(locale.LC_ALL, 'fr_FR')
>>> locale.localize('{:.2f}'.format(1.891))
'1,89'

[alexander-gabriel]

Individually localizing numbers is not a viable solution to this problem. str.format() allows us to efficiently produce strings with lots of numbers...but only if you don't need localization. Localizing 10 or 20 numbers individually is verbose, inefficient and simply bad style.

Python should allow users to use the full power of str.format() in a localized manner.

[ericvsmith]

Thanks everyone for their input, but I'm going to close this issue. Given that there's a workaround to use the locale module directly, I think that's the best approach. One day I'd like to see a way of using locales that doesn't depend on the C standard library and all of its baggage, but until then let's leave locales alone.