[Django] #21544: Problem with number format when not using L10N
Django
----------------------------+---------------------------
Reporter: yceruto@… | Owner: Yonel Ceruto
Type: Bug | Status: new
Component: Utilities | Version: 1.6
Severity: Normal | Keywords: number format
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 1 | UI/UX: 0
----------------------------+---------------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/21544>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: yceruto@… | Owner: Yonel Ceruto
Component: Utilities | Version: 1.6
Severity: Normal | Resolution: wontfix
Keywords: number format | Triage Stage: Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Changes (by claudep):
* status: new => closed
* needs_better_patch: => 0
* resolution: => wontfix
* needs_tests: => 0
* needs_docs: => 0
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/21544#comment:1>
Django
Reporter: yceruto@… | Owner: Yonel Ceruto
Component: Utilities | Version: 1.6
Severity: Normal | Resolution: wontfix
Keywords: number format | Triage Stage: Unreviewed
Easy pickings: 1 | UI/UX: 0
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/21544#comment:2>
Django
Reporter: yceruto@… | Owner: Yonel Ceruto
Component: Utilities | Version: 1.6
Severity: Normal | Resolution: wontfix
Keywords: number format | Triage Stage: Unreviewed
Easy pickings: 1 | UI/UX: 0
Comment (by 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?
--
Ticket URL: <https://code.djangoproject.com/ticket/21544#comment:3>
Django
Reporter: yceruto@… | Owner: Yonel Ceruto
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: number format | Triage Stage: Unreviewed
Easy pickings: 1 | UI/UX: 0
Changes (by yceruto@…):
* status: closed => new
* version: 1.6 => master
* resolution: wontfix =>
--
Ticket URL: <https://code.djangoproject.com/ticket/21544#comment:4>
Django
Reporter: yceruto@… | Owner: Yonel Ceruto
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: number format | Triage Stage: Unreviewed
Easy pickings: 1 | UI/UX: 0
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/21544#comment:5>
Django
Reporter: yceruto@… | Owner: Yonel Ceruto
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: number format | Triage Stage: Unreviewed
Easy pickings: 1 | UI/UX: 0
Comment (by claudep):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/21544#comment:6>
Django
Reporter: yceruto@… | Owner: Yonel Ceruto
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: number format | Triage Stage: Unreviewed
Easy pickings: 1 | UI/UX: 0
Comment (by 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
--
Ticket URL: <https://code.djangoproject.com/ticket/21544#comment:7>
Django
Reporter: yceruto@… | Owner: Yonel Ceruto
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: number format | Triage Stage: Unreviewed
Easy pickings: 1 | UI/UX: 0
Comment (by 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
--
Ticket URL: <https://code.djangoproject.com/ticket/21544#comment:8>
Django
Reporter: yceruto@… | Owner: Yonel Ceruto
Component: Utilities | Version: master
Severity: Normal | Resolution: wontfix
Keywords: number format | Triage Stage: Unreviewed
Easy pickings: 1 | UI/UX: 0
Changes (by shai):
* status: new => closed
* cc: shai (added)
* resolution: => wontfix
Comment:
Replying to [comment:7 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/21544#comment:9>
Django
Reporter: yceruto@… | Owner: Yonel Ceruto
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: number format | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 1 | UI/UX: 0
Changes (by shai):
* status: closed => new
* resolution: wontfix =>
* stage: Unreviewed => Accepted
Comment:
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
{{{#!python
use_grouping = settings.USE_L10N and settings.USE_THOUSAND_SEPARATOR
}}}
to
{{{#!python
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/21544#comment:10>
Django
Reporter: yceruto@… | Owner: Yonel Ceruto
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: number format | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
-------------------------------+----------------------------------------
Changes (by timo):
* easy: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/21544#comment:11>
Django
Reporter: yceruto@… | Owner: Jacob Walls
Type: Bug | Status: assigned
Component: Documentation | Version: dev
Severity: Normal | Resolution:
Keywords: number format | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+---------------------------------------
* owner: Yonel Ceruto => Jacob Walls
* status: new => assigned
* component: Utilities => Documentation
Comment:
> 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 tag `floatformat`; in that instance, see
<docs about forcing thousand separators in floatformat>.
--
Ticket URL: <https://code.djangoproject.com/ticket/21544#comment:12>
Django
Reporter: yceruto@… | Owner: Jacob Walls
Type: Bug | Status: assigned
Component: Documentation | Version: dev
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+---------------------------------------
Changes (by Jacob Walls):
* has_patch: 0 => 1
Comment:
[https://github.com/django/django/pull/14516 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/21544#comment:13>
Django
Reporter: yceruto@… | Owner: Jacob Walls
Component: Documentation | Version: dev
Severity: Normal | Resolution: duplicate
Keywords: number format | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+---------------------------------------
* status: assigned => closed
* resolution: => duplicate
Comment:
Closing as a duplicate of #32873 — which will remove the `USE_L10N`
setting, rendering this moot.
--
Ticket URL: <https://code.djangoproject.com/ticket/21544#comment:14>