Underscores in Python numbers

[Steven D'Aprano]

On Sun, 20 Nov 2005 09:27:28 -0500, Peter Hansen wrote:

> But why would anyone want to create numeric literals for credit card 
> numbers?


Credit card numbers is not a sensible usage case. Neither are books'
ISBNs, or tax file numbers, or telephone numbers -- these are all
instances where it makes sense to read them from a data file and use a
converter function.

One sensible usage case is numeric calculations, where you often are
using numeric constants in some formula, and those constants may have ten,
twelve, fifteen digits. Being able to group digits makes it considerable
easier to enter the numbers, as well as proof-read your code.

c = 25.173 268 901 910 023

is considerably easier for the human reader to parse than:

c = 25.173268901910023

Calculating the number in place is not an acceptable solution:

c = 25.173 + 268e-3 + 901e-6 + 910e-9 + 23e-12

is bad for a number of reasons:

- it implies c is a calculated sum when it is not;
- it harms comprehension;
- it may very well lose accuracy;
- it is easy to miscalculate and end up with a completely wrong number;
- it complicates and obfuscates the compiled code.

Another sensible usage case is in the interactive interpreter. If you are
using Python interactively, you may wish to use numeric literals with
large numbers of digits. It is not feasible to read them from a data file,
and using a special converter function is impractical and unnecessary.

I don't know whether these two usage cases will be enough to justify
changing the way Python handles numeric literals -- Guido seems quite
conservative in what he adds to the language, so unless there is either
great demand or it scratches a particular itch he has personally, I doubt
it will fly. But we'll never know unless we try, hey? *wink*


-- 
Steven.