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. -- http://mail.python.org/mailman/listinfo/python-list
