Problem with number format when not using L10N

[yceruto@…]

My system at one point tries to display a number in a specific format, for which I use the "floatformat" filter.

My configuration in "settings.py" is:
USE_L10N = False
USE_THOUSAND_SEPARATOR = True
NUMBER_GROUPING = 3

The problem is that the "floatformat" filter uses the "format" utility and this in turn applies the grouping of thousands if L10N is true:

use_grouping = settings.USE_L10N and settings.USE_THOUSAND_SEPARATOR

From the "floatformat" filter I can not force the grouping of thousands, making it impossible to apply this option. Showing my number without the grouping of thousands.

[Claude Paroz]

A built-in filter will never allow the full flexibility of the internal formatting API. If you have specific needs, I'd suggest writing your own custom filter, or prepare the formatting of the float value in the view. If you think there might be an obvious way to allow that flexibility, reopen with a concrete suggestion or write the proposal to the django-developers mailing list.

[yceruto@…]

My proposal is clear here ​https://github.com/django/django/pull/2015 and I see no reason to make a custom filter when I should show the grouping of thousands according to my configuration, thanks.

[yceruto@…]

I want to use the grouping of thousands in my numeric formats, for which I use the "floatformat" filter.

My configuration in "settings.py" is:
USE_L10N = False
USE_THOUSAND_SEPARATOR = True
NUMBER_GROUPING = 3

Showing my numbers without the grouping of thousands.

When I check in depth the why, I realize that the grouping of thousands is subject to the value of the Variable settings.USE_L10N:

django/utils/numberformat.py:

def format (...):
...
use_grouping = settings.USE_L10N and settings.USE_THOUSAND_SEPARATOR

Think it would be correct to eliminate the constraint that prohibits the display grouping of thousands, if not L10N used?

[yceruto@…]

I think the configuration of the variable USE_L10N aims at in this case to determine the format of number and not condition the use of the grouping of thousands.

[Claude Paroz]

The current behavior is documented:
When USE_L10N is set to True and if this is also set to True, Django will use the values of THOUSAND_SEPARATOR and NUMBER_GROUPING to format numbers.
​https://docs.djangoproject.com/en/dev/ref/settings/#use-thousand-separator

If suddenly we change the rules, people might unexpectedly see thousands separators, for example in a section where they have temporarily disabled l10n. So the change you proposes is not applicable as is.

I'll let someone else decide if something should/could be done here or simply closed again.

[yceruto@…]

I do not understand why mention the word "unexpectedly"?

It is understood that if I have enabled the thousands separator USE_THOUSAND_SEPARATOR = True and NUMBER_GROUPING > 0 to display all numbers with the pattern:

#THOUSAND_SEPARATOR###DECIMAL_SEPARATOR##

If is enabled or not USE_L10N only determines the "values" ​​of DECIMAL_SEPARATOR and THOUSAND_SEPARATOR according to the current locate set to LANGUAGE_CODE, but if USE_L10N = False then is display the default values.

Why USE_L10N determining use of thousands separator?

​https://docs.djangoproject.com/en/dev/ref/settings/#use-l10n
Here not speak of this variable determines the use of the thousands separator.

Please clarify, thanks

[yceruto@…]

So the following example will not take effect:

USE_L10N = False
USE_THOUSAND_SEPARATOR = True
THOUSAND_SEPARATOR = ','
NUMBER_GROUPING = 3
DECIMAL_SEPARATOR = '.'

You should see 1,000.23
When today really shows 1000.23 due to the problem that I explain above

[Shai Berger]

Replying to yceruto@…:

I do not understand why mention the word "unexpectedly"?

Because, as Claude mentioned, the current behavior of the code agrees with the documentation. You may have misinterpreted the documentation.

[...]

If is enabled or not USE_L10N only determines the "values" ​​of DECIMAL_SEPARATOR and THOUSAND_SEPARATOR according to the current locate set to LANGUAGE_CODE, but if USE_L10N = False then is display the default values.

That is not what the documentation says.

Why USE_L10N determining use of thousands separator?

​https://docs.djangoproject.com/en/dev/ref/settings/#use-l10n
Here not speak of this variable determines the use of the thousands separator.

​https://docs.djangoproject.com/en/dev/ref/settings/#use-thousand-separator
Here it does. If it is not clear to you that it does, you may consider suggesting a clarification.

Although Claude was extra-nice about it, in the future, please do not reopen a ticket that was closed as "wontfix" by a core committer. You can take the discussion to the developers list; I note that, in this case, you did that too (​https://groups.google.com/d/msgid/django-developers/6a31612c-1052-4b37-bfbb-1c707934dc11%40googlegroups.com) -- but that discussion didn't pick up much steam. You may want to revisit it.

[Shai Berger]

Important points from discussion:

The documentation for USE_THOUSAND_SEPARATOR implies that it only has effect when USE_L10N is on, and current behavior is correct.
The documentation for NUMBER_GROUPING and THOUSAND_SEPARATOR says (on each of them):

Note that if USE_L10N is set to True, then the locale-dictated format has higher precedence and will be applied instead.

implying that when USE_L10N is False, the values should be used, and the submitter is correct.

So it seems like the documentation is not entirely consistent, and at the very least it should be clarified.

One way to interpret the documentation consistently is: USE_THOUSAND_SEPARATOR is a sort of partial override, indicating that NUMBER_GROUPING and THOUSAND_SEPARATOR should be used even though USE_L10N is on -- in that case the submitter is probably correct, and the line he refers to should be changed from

use_grouping = settings.USE_L10N and settings.USE_THOUSAND_SEPARATOR

to

use_grouping = (not settings.USE_L10N) or settings.USE_THOUSAND_SEPARATOR

Either way, marking as accepted as there clearly is a discrepancy between the code and parts of the documentation. Something needs to be fixed.

[Jacob Walls]

From the "floatformat" filter I can not force the grouping of thousands, making it impossible to apply this option.

Forcing thousand separators in floatformat was new in 3.2: see ac6c4260074de43a978e5c6553ef89441e1d6748 (#20601).

So I think we have solved the original use case. Regarding the documentation inconsistency noted by Shai:

implying that when USE_L10N is False, the values should be used, and the submitter is correct.
So it seems like the documentation is not entirely consistent, and at the very least it should be clarified.

The current behavior was created in 10d4094b86721da690fcb3c9bc89b7a0089dfd5c (#13054). See this test:

    @override_settings(USE_L10N=False)
    def test_l10n_disabled(self):
            ...
            # We shouldn't change the behavior of the floatformat filter re:
            # thousand separator and grouping when USE_L10N is False even
            # if the USE_THOUSAND_SEPARATOR, NUMBER_GROUPING and
            # THOUSAND_SEPARATOR settings are specified
            with self.settings(USE_THOUSAND_SEPARATOR=True, NUMBER_GROUPING=1, THOUSAND_SEPARATOR='!'):
                self.assertEqual('66666.67', Template('{{ n|floatformat:2 }}').render(self.ctxt))
                self.assertEqual('100000.0', Template('{{ f|floatformat }}').render(self.ctxt))

Rationale from #13054 discussion:

I'm inclined to think it is a bug because this hypothetical scenario: An user has set NUMBER_GROUPING to a value > 0 and USE_THOUSAND_SEPARATOR = True but sets USE_L10N = False thinking it's a master switch that turns the locale-aware formatting machinery off. But the floatformat filter still messes with the part to the left of the decimal separator.

So we have evidence the current behavior is intentional. However, elsewhere we've been going in the other direction, which makes updating the docs all the more important.

The approach in #22654 was to respect THOUSAND_SEPARATOR and DECIMAL_SEPARATOR even when L10N=False for form validation:
bde814142a933bd96c3fa54a64cb1f74a575bb38
504e7782fef74cb78768092780a3476866379c21 (release note)

Unless we want to change numberformat a second time (!), and given that we've enabled the reporter's use case with an option to force thousand separators in floatformat, maybe we should clarify the difference in behavior in the documentation for these settings? Something like: when USE_L10N is False, these settings are respected only for form validation, not for the template filter floatformat; in that instance, see <docs about forcing thousand separators in floatformat>.

[Jacob Walls]

​PR

[Carlton Gibson]

Closing as a duplicate of #32873 — which will remove the USE_L10N setting, rendering this moot.