It would be nice if pprint learned to insert underscores in long numbers

Current behavior:

>>> pprint.pprint(int(1e9))
1000000000

Desired behavior

>>> pprint.pprint(int(1e9))
1_000_000_000

Wikipedia tells me that "groups of 3" is the international standard to be followed here [1][2]

[1] https://en.wikipedia.org/wiki/ISO_31-0#Numbers
[2] https://en.wikipedia.org/wiki/Decimal_separator#Digit_grouping

Here is an implementation of the safe repr for numbers if helpful:

def safe_repr_int(object):
    sign = ''
    if object < 0:
        sign = '-'
        object  = -object
    r = repr(object)
    if len(r) <= 4:
        return sign + r
    parts = [sign]
    left = len(r) % 3
    if left:
        parts.append(r[0:left])
        parts.append('_')
        r = r[left:]
    parts.append(r[0:3])
    for i in range(3, len(r), 3):
        parts.append('_')
        parts.append(r[i:i + 3])
    return ''.join(parts)

It would be nice if pprint learned to insert underscores in long numbers

+1 but I would make this optional.

Here is an implementation of the safe repr for numbers if helpful

I suggest using the existing string formatting tools as a foundation

    >>> format(10**9, ',d').replace(',', '_')
    '1_000_000_000'

+1 also. I agree with Raymond it should be optional.

I add the same idea but later than you, so I'm interested by such feature.

Felipe: do you want to add a pull request to this issue (with Serhiy Storchaka implementation because it's the simplest one)?

If not, I plan to write it.
I will write it too if there is no reply in one month.

All yours! I'm tied up so won't be able to submit the PR

On Thu, 25 Feb 2021 at 10:12, Stéphane Blondon <report@bugs.python.org>
wrote:

Stéphane Blondon <stephane.blondon@gmail.com> added the comment:

I add the same idea but later than you, so I'm interested by such feature.

Felipe: do you want to add a pull request to this issue (with Serhiy
Storchaka implementation because it's the simplest one)?

If not, I plan to write it.
I will write it too if there is no reply in one month.

----------
nosy: +sblondon

---

Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue42914\>

---

Thank you Felipe for the news! :)
I have committed a PR about this issue.

Two remarks:

• I changed the proposed implementation from 'format(integer, '_d')' to '{:_d}.format(integer)' because the first way raised an exception. (The format function was not defined.)
• I thought about adding the same behavior for float too but I didn't add it because the 'f' type uses a precision of 6 digits after the decimal point for float. So it's possible some precision would be lost with the pprint() call. It could mislead users more than helping them with the readability of the ''. A precision value can be added but I'm not sure it's a good idea. based on [1]

As requested, there is a new parameter to disable this new behavior ('underscore_numbers').

1: https://docs.python.org/3/library/string.html#format-specification-mini-language

I don't think underscores can be on by default. It needs to be opt-in to be backwards compatible.

I changed the default to be backward compatible (so underscore_numbers=False).

I think it would be better with underscore_numbers enabled by default but I understand the need for stability. Perhaps such break could be done in the future (in version 3.12 or v.4)?

New changeset 3ba3d51 by sblondon in branch 'master':
bpo-42914: add a pprint underscore_numbers option (GH-24864)
3ba3d51

Thanks for the contribution Stéphane!

I agree that this would be a nice default. We're just being conservative in the pace of default behavior changes. Changing the default could be considered in the future after a few releases with this parameter have shipped.

New changeset 4846ea9 by Wm. Keith van der Meulen in branch 'main':
Add bpo-42914 to What's New (GH-25124)
4846ea9

New changeset 4131780 by Miss Islington (bot) in branch '3.10':
Add bpo-42914 to What's New (GH-25124)
4131780

Python 3.10 has now been released with the underscore_numbers parameter.
I wonder which release could enable the parameter by default (so it would break the previous behavior):

• the next release (3.11) is probably too short.
• the safest strategy is to wait until 3.9 will be end-of-life (2025-10 according to [1]). In such case, it could be integrated in 3.14.

Could it be accepted before (like 3.12 or 3.13)?

If there is no reply, I will create a new issue and PR for 3.14 inclusion ( = safest strategy).

1: https://devguide.python.org/#status-of-python-branches

The safest thing to do is never make it the default. It would always be an opt-in behavior.

Ok, I will not send a PR to change the current behavior until python4 (in case it exists one day).