This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: pprint numbers with underscore
Type: enhancement Stage: commit review
Components: Library (Lib) Versions: Python 3.10
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: eric.smith, fov, gregory.p.smith, mark.dickinson, miss-islington, rhettinger, sblondon, serhiy.storchaka, wkeithvan
Priority: normal Keywords: patch

Created on 2021-01-12 23:21 by fov, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 24864 merged sblondon, 2021-03-14 22:23
PR 25124 merged wkeithvan, 2021-04-01 01:30
PR 26509 merged miss-islington, 2021-06-03 03:45
Messages (17)
msg384982 - (view) Author: Felipe (fov) * Date: 2021-01-12 23:21
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
msg384985 - (view) Author: Felipe (fov) * Date: 2021-01-12 23:50
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)
```
msg384992 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2021-01-13 03:35
> 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'
msg385025 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2021-01-13 13:37
+1 also. I agree with Raymond it should be optional.
msg385034 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2021-01-13 15:04
>>> format(10**9, '_d')
'1_000_000_000'
msg387677 - (view) Author: Stéphane Blondon (sblondon) * Date: 2021-02-25 15:12
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.
msg388390 - (view) Author: Felipe (fov) * Date: 2021-03-09 21:52
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>
> _______________________________________
>
msg388693 - (view) Author: Stéphane Blondon (sblondon) * Date: 2021-03-14 22:42
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
msg389205 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2021-03-21 01:37
I don't think underscores can be on by default.  It needs to be opt-in to be backwards compatible.
msg389319 - (view) Author: Stéphane Blondon (sblondon) * Date: 2021-03-22 14:10
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)?
msg389439 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2021-03-24 08:23
New changeset 3ba3d513b1e3c63d09cb798b982a9e6c369cea4c by sblondon in branch 'master':
bpo-42914: add a pprint underscore_numbers option (GH-24864)
https://github.com/python/cpython/commit/3ba3d513b1e3c63d09cb798b982a9e6c369cea4c
msg389440 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2021-03-24 08:28
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.
msg394979 - (view) Author: miss-islington (miss-islington) Date: 2021-06-03 03:45
New changeset 4846ea95d1a121df5e8081e2a290f63d1419cad8 by Wm. Keith van der Meulen in branch 'main':
Add bpo-42914 to What's New (GH-25124)
https://github.com/python/cpython/commit/4846ea95d1a121df5e8081e2a290f63d1419cad8
msg394981 - (view) Author: miss-islington (miss-islington) Date: 2021-06-03 04:05
New changeset 41317801a95c758c3fc04c4fb332ac453c9e3ad3 by Miss Islington (bot) in branch '3.10':
Add bpo-42914 to What's New (GH-25124)
https://github.com/python/cpython/commit/41317801a95c758c3fc04c4fb332ac453c9e3ad3
msg403225 - (view) Author: Stéphane Blondon (sblondon) * Date: 2021-10-05 10:56
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
msg403226 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2021-10-05 10:59
The safest thing to do is never make it the default. It would always be an opt-in behavior.
msg403525 - (view) Author: Stéphane Blondon (sblondon) * Date: 2021-10-09 09:15
Ok, I will not send a PR to change the current behavior until python4 (in case it exists one day).
History
Date User Action Args
2022-04-11 14:59:40adminsetgithub: 87080
2021-10-09 09:15:33sblondonsetmessages: + msg403525
2021-10-05 10:59:16eric.smithsetmessages: + msg403226
2021-10-05 10:56:11sblondonsetmessages: + msg403225
2021-06-03 04:05:47miss-islingtonsetmessages: + msg394981
2021-06-03 03:45:44miss-islingtonsetpull_requests: + pull_request25105
2021-06-03 03:45:41miss-islingtonsetnosy: + miss-islington
messages: + msg394979
2021-04-01 01:30:12wkeithvansetnosy: + wkeithvan

pull_requests: + pull_request23872
2021-03-24 08:28:50gregory.p.smithsetstatus: open -> closed
resolution: fixed
messages: + msg389440

stage: patch review -> commit review
2021-03-24 08:23:34gregory.p.smithsetmessages: + msg389439
2021-03-22 14:10:36sblondonsetmessages: + msg389319
2021-03-21 01:37:23rhettingersetmessages: + msg389205
2021-03-20 23:32:18gregory.p.smithsetnosy: + gregory.p.smith
2021-03-14 22:42:53sblondonsetmessages: + msg388693
2021-03-14 22:23:19sblondonsetkeywords: + patch
stage: patch review
pull_requests: + pull_request23624
2021-03-09 21:52:59fovsetmessages: + msg388390
2021-02-25 15:28:49mark.dickinsonsetnosy: + mark.dickinson
2021-02-25 15:12:45sblondonsetnosy: + sblondon
messages: + msg387677
2021-01-13 15:04:56serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg385034
2021-01-13 13:37:23eric.smithsetnosy: + eric.smith
messages: + msg385025
2021-01-13 03:35:29rhettingersetnosy: + rhettinger
messages: + msg384992
2021-01-12 23:50:25fovsetmessages: + msg384985
2021-01-12 23:21:21fovcreate