Bruce Leban wrote:
Consider these examples instead:
- 1_234_000 - 9.876_543_210 - 0xFEFF_0042
I'm not advocating this change (nor against it); I just think the discussion should be focused on the actual idea. I do have a question:
Is _ just ignored in numbers or are there more complex rules?
- 1_2345_6789 (can I use groups of other sizes instead?) - 1_2_3_4_5 (ditto) - 1_234_6789 (do all the groups need to be the same size?)
+1 on all of these. I don't particularly like the look of _ as a number separator, but it's hard to think of any alternatives other than space, and some separator is better than long sequences of digits. I'm -0.5 on spaces even though it looks MUCH better, because it's too easy to leave the commas out in lists etc: L = [1, 2, 3, 4 5, 6, 7, 8, 9, 10] # oops, wanted 4 & 5 not 45 (Admittedly if the items where strings, the same failure mode applies.)
- 1_ (must the _ only be in between 2 digits?) - 1__234 (what about multiple _s?)
-1 on allowing either _1 or 1_ as numbers. -0 on allowing doubled underscores.
- 9.876_543_210 (can it be used to the right of the decimal point?) - 0xFEFF_0042 (can it be used in hex, octal or binary numbers?)
+1 on these two.
- int('123_456') (do other functions accept this syntax too?)
That's a tricky one... I'd say No, but I'm not entirely sure. It's easy enough to say: int('123_456'.replace('_', '')) albeit a tad verbose. Also easy to say: int('123' '456') which is less verbose. And it will change the behaviour of the int function. So I don't think we need to support separators inside strings. We can always change our mind later and add it in, but it's much harder to take it out later. -- Steven