id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
32810	django.utils.formats.number_format calculates a value for use_l10n which isn't re-used for calls to get_format	Keryn Knight	Mateo Radman	"Currently, the first thing `number_format` does is:

{{{
    if use_l10n or (use_l10n is None and settings.USE_L10N):
        lang = get_language()
    else:
        lang = None
}}}

so that it can pass the `lang` (string/None) and `use_l10n` (boolean/None) through to the `get_format` function. The `get_format` function is used 3 times for the one `number_format` call  (which in turn is used for every call to `localize` via `render_value_in_context`)

The first thing `get_format` does, meanwhile, is much the same:
{{{
    use_l10n = use_l10n or (use_l10n is None and settings.USE_L10N)
    if use_l10n and lang is None:
        lang = get_language()
}}}

As far as I can tell, a small micro-optimisation is available in `number_format` to pre-calculate the `use_l10n` value and if it's truthy avoid a few comparisons. I don't **think** it's subject to any threadlocal values changing in between:

{{{
def number_format(value, decimal_pos=None, use_l10n=None, force_grouping=False):
    ...
    use_l10n = use_l10n or (use_l10n is None and settings.USE_L10N)
    if use_l10n:
        lang = get_language()
    else:
        lang = None
    ...
}}}
At worst it'd continue re-calculating the use_l10n value within `get_format` because it's previously been evaluated as falsy, I think.

(Addendum: Having briefly glanced at it, I don't think this affects/steps on the toes of #25762 which sounds like a much bigger/better win)"	Cleanup/optimization	closed	Utilities	dev	Normal	fixed			Accepted	1	0	0	0	1	0