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: PEP 3101 string formatting missing hexadecimal separator _ for every 4 hex digits
Type: enhancement Stage:
Components: Versions: Python 3.2, Python 2.7
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: eric.smith, hardkrash, mark.dickinson
Priority: normal Keywords:

Created on 2010-03-04 21:46 by hardkrash, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (6)
msg100422 - (view) Author: steven Michalske (hardkrash) Date: 2010-03-04 21:46
It is a common practice to separate hex digits with a "thousands" separator every 4 hex digits.

0x1234_abcd

Although python does not accept the _ as a thousands separator in hex notation, neither is the thousands separator in base 10


Snippet that prints hex thousands with a _ separator

number = 0xef5678abcd1234

def hex_thousands(number):
    txt="{0:X}".format(number)
    txt_out = ""
    i = range(-4,-1 * (len(txt) + 4), -4)
    ii = i[:]
    ii.insert(0, None)
    for (j, k) in zip(i, ii):
        if txt_out:
            txt_out = "_" + txt_out
        txt_out = txt[j:k] + txt_out
    return txt_out

print hex_thousands(number)
msg100458 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-03-05 09:38
How common is this 'common practice'?  Could you point to some publicly available examples? Are there other languages that have built-in facilities for dealing with hexadecimal representations of integers in this way?

I think I've seen hex strings separated by spaces every four digits, and by spaces or colons every two digits (though the latter was usually used for something that's better seen as a sequence of bytes rather than a hexadecimal representation of a large integer).  I've rarely seen the underscore separation that you describe, but perhaps that's because I haven't been looking in the right places.

Do you have a concrete proposal for amending the formatting mini-language syntax to support this?  Perhaps you could run this past the python-ideas mailing list to try to get support and to thrash out the details of a possible specification?

To me this seems to be adding yet more complication to an already complicated formatting mini-language for something that few people will ever need, so I'd be -1 on this as it stands.
msg100459 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-03-05 09:50
Closing this for now;  if you want to pursue this, please take the suggestion to the python-ideas mailing list.
msg100508 - (view) Author: steven Michalske (hardkrash) Date: 2010-03-06 01:32
I'll work on a proposal for the ideas list.

Other language examples to keep this in a thread though.

perl -e 'print 0x1234_abcd; print "\n";'

C/C++ seems to not support the underscore.
Lua unsupported.

Data sheets from micro controllers and other digital circuits.

Bottom of page 21 on http://www.atmel.com/dyn/resources/prod_documents/32058S.pdf
msg100521 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-03-06 09:10
I'm confused:  are you talking about producing underscores when formatting an integer for hexadecimal output, or allowing numeric literals to contain underscores?

Your perl example produces:

305441741

with not an underscore in sight.  I'm failing to understand the relevance of this example to your request.
msg100552 - (view) Author: steven Michalske (hardkrash) Date: 2010-03-06 23:56
Sorry my request is for output,  I am not requesting input.  The examples were for showing the use in other contexts of using an underscore as a word (4 hex digits) seperaror.

My assertions are from another area aside from computer languages,  but from documentation for components.  So I showed a documentation example and software examples that used or would not accept underscores.

the common pratice of using a space is not good for computer output to be used for parsing in following applications.
History
Date User Action Args
2022-04-11 14:56:58adminsetgithub: 52309
2010-03-06 23:56:51hardkrashsetmessages: + msg100552
2010-03-06 09:10:31mark.dickinsonsetmessages: + msg100521
2010-03-06 01:32:12hardkrashsetmessages: + msg100508
2010-03-05 09:50:37mark.dickinsonsetstatus: open -> closed
resolution: rejected
messages: + msg100459
2010-03-05 09:38:48mark.dickinsonsetmessages: + msg100458
2010-03-04 21:48:26ezio.melottisetpriority: normal
nosy: + mark.dickinson, eric.smith

type: enhancement
versions: + Python 3.2, - Python 3.3
2010-03-04 21:46:44hardkrashcreate