Add underscores to numeric literals with more than 6 digits

[zsol]

No description provided.

[coveralls]

Pull Request Test Coverage Report for Build 751

• 14 of 15 (93.33%) changed or added relevant lines in 3 files are covered.
• 28 unchanged lines in 3 files lost coverage.
• Overall coverage increased (+0.3%) to 96.197%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
black.py	4	5	80.0%

Files with Coverage Reduction	New Missed Lines	%
blackd.py	2	38.89%
tests/test_black.py	3	67.36%
black.py	23	66.14%

Totals
Change from base Build 743:	0.3%
Covered Lines:	2909
Relevant Lines:	3024

---

💛 - Coveralls

[zsol]

@JelleZijlstra thanks for reviewing :) We decided to just use underscores for numbers longer than 4 digits as that's simpler to understand for users (less surprising behavior) as well as 12345 is just as unreadable as 10000 for some people.

[JelleZijlstra]

Sure, that's fine with me too, probably better because it's a simpler rule.

[ghost]

I like the idea but black is supposed to be the same for everyone and this would force western digit grouping onto all users. Concrete example: India would write 1_00_000 and not 100_000.

https://en.wikipedia.org/wiki/Indian_numbering_system

You wouldn't change quoted text strings, so why digits?

[ambv]

Four digits is a little noisy, it's not really necessary for readability at that level. It would be way less controversial to standardize from six digits up. E.g.:

1
123
1023
12023
123_023
1_123_023
...

@Thalessa, thanks for bringing this up! The point of Black is to standardize everything so that code will look the same regardless of your project. Countries have differing standards, another popular example is the usage of a comma or a period for the decimal point separator (in Poland we use the comma). In this case, unless your project is local to the Indian subcontinent and does not anticipate any external contribution, standardizing on Indian separators is out of the question. So Black won't do that.

However, I do recognize that if you were raised with the Indian numbering system in school, your brain is hard-wired now to read numbers like this. In other words, it's not just about the separators, it's about reading the numbers in your mind. Forcing an incompatible standard here is harsh.

Thus, I think we need -N or --skip-number-normalization. Just like with -S, it doesn't let you configure how to standardize, but it lets you opt out if the standardization hurts productivity on your particular project.

[ambv]

I'm reading about this some more now and in fact in Chinese numerals are grouped by tens-of-thousands:

System	Notation	Reading
Western	12,345,678,902,345	(12) [1,000,000,000,000] (345) [1,000,000,000] (678) [1,000,000] (902) [1,000] (345) [1]
Chinese	12,3456,7890,2345	(12) [1,0000,0000,0000] (3456) [1,0000,0000] (7890) [1,0000] (2345) [1]

This reinforces my thinking that we should let certain projects opt out with -N.

[zsol]

Wow this looks ugly

[ambv]

Would you rather have this be extra one-indented? That's possible but unprecedented in Black so far. We can also wrap the entire value in optional parentheses but then you will have four lines instead of two.

[zsol]

I personally prefer the optional parentheses even if it makes the expression break over 4 lines. Not sure if that is the best way to go in the general case, though.