Select the compact pattern from the rounded value

[Sreekant13]

format_compact_decimal picks the magnitude bucket from the unrounded number and only rounds afterwards, so a value that rounds up into the next magnitude keeps the smaller unit:

>>> from babel.numbers import format_compact_decimal
>>> format_compact_decimal(999999, locale='en_US', format_type='short')
'1000K'          # expected '1M'
>>> format_compact_decimal(999999999, locale='en_US', format_type='short')
'1000M'          # expected '1B'
>>> format_compact_decimal(999999, locale='en_US', format_type='long')
'1000 thousand'  # expected '1 million'

"1000K" is not a valid compact form, since the mantissa is supposed to stay below the next magnitude. The CLDR algorithm that _get_compact_format links in its own docstring selects the pattern from the rounded value, so this redoes the lookup one magnitude up when rounding carries over.

The retry goes through _get_compact_format again rather than patching the pattern in place, so the next bucket's plural form is re-selected too; that is what makes the long format read "1 million" instead of "1 millions". It terminates because the bumped value sits exactly on the magnitude boundary and cannot carry a second time.

Values that do not carry over are unaffected: 999 -> 999, 1000 -> 1K, 99999 -> 100K, 9999999 -> 10M, 999949 with fraction_digits=1 -> 999.9K, 12345 with fraction_digits=2 -> 12.34K. Negatives keep their sign (-999999 -> -1M).

Added test_compact_rounding_carries_to_next_magnitude; it fails on the current code with assert '1000K' == '1M'.

[akx]

Note that tests/test_dates.py fails heavily in my environment with LookupError: Unknown timezone because tzdata is unavailable; those failures are identical with this change reverted and are unrelated to it.

You should fix your environment. Unless, of course, this comment was maybe written by an agent in a sandbox.

[Sreekant13]

You were right, my checkout had CLDR 47 imported while master expects 48.2. I have re-run scripts/download_import_cldr.py and the full suite now passes: 6608 passed, 1166 skipped, 1 xfailed. Sorry for the misleading note, I have removed it from the description. The branch is also rebased onto current master.

[Sreekant13]

Hi @akx, a gentle check-in, and no rush.

You were right about my environment back in July, and I wanted to make sure my answer did not get lost. My checkout had CLDR 47 imported while master expects 48.2, which is what produced the unrelated failures I had reported. I re-ran scripts/download_import_cldr.py, rebased onto master, and the full suite is 6608 passed with 0 failures. The stash-prove still holds: with the fix reverted, test_compact_rounding_carries_to_next_magnitude fails on '1000K' == '1M'.

On the change itself: format_compact_decimal picks the magnitude from the unrounded value and then rounds, so a rounding carry keeps the smaller unit. 999999 renders as '1000K' rather than 1M, and long form gives '1000 thousand' rather than 1 million. Per UTS #35, which the function's own docstring links, the pattern is selected from the rounded value.

Happy to answer anything else, or to close it if you would rather this were solved a different way.