Wemake-python-styleguide: Enforce consistent octal, hex, and binary numbers

[sobolevn]

Rule request

Thesis

We should write consistent numbers:

• 0b1 instead of 0b0001, 0b001 == 0b1
• 0x1 instead of 0x001
• 0o5 instead of 0o05

Reasoning

Numbers should be consistent.

[kxepal]

That's doubt. Zero padding exists for readability, but not a mistake reasons.

[sobolevn]

@kxepal can you please provide an example where having multiple zeros improves readability?

[kxepal]

Well, let's take short hand encoding example: https://github.com/python/cpython/blob/master/Lib/encodings/cp866.py#L47-L176

Each character of single byte cp866 maps on one-two bytes unicode one. While keys in this example may be left zero-trimmed, the values will reduce readability by such action. Having both length synced looks nicer and reads well.

[sobolevn]

@kxepal thanks for bringing this up. Indeed, sometimes inconsistent behaviour can be occasionally more readable.

But, this discussion motivated me to formulate the philosophy behind my decisions: https://wemake-python-styleguide.readthedocs.io/en/latest/pages/api.html#philosophy

So, we are interested in these two parts:

Consistency over syntatic readability
Consistent code is more readable than inconsistent

I strongly believe that it is easier to read numbers when there's only a one way to write them.
As in math. Not multiple ways as in python.

But, you suggestion is perfectly reasonable and helpful. Much thanks, so awesome.

[kxepal]

You're welcome! :beers:

[astynax]

What do you thing about such rules?

• "binary literals should have 2, 4, 8 or 8n digits" (binary literals are very useful in hardware related, so readable bit order and positioning are very important!)
• "hexadecimal literals should have 2n digits" (colors in RGB(A) for example)

[sobolevn]

I really like the suggestion made by @astynax
@AndreyErmilov please, take a look.

[AndreyErmilov]

@sobolevn Thanks for reviewing the PR!
I can't make a complete issue description with the @astynax suggestion. Help me please.

[sobolevn]

@AndreyErmilov what do you mean by "complete issue description"?

[sobolevn]

@AndreyErmilov now I get it. Here's the full description:

• "binary literals should have 2, 4, 8 or 8n digits" (binary literals are very useful in hardware related, so readable bit order and positioning are very important!)
• "hexadecimal literals should have 2n digits" (colors in RGB(A) for example)
• octal number should have 2n digits

[sobolevn]

Ok, after reviewing two PRs, thinking hard, and playing around, I have made a decision about this rule.

We are not going to support any leading zeros. If someone wants formatting, switch off this rule for this file, line, etc.

We value consistency more.

Why do leading zeros not fit in this rule? Let me show several examples to you:

>>> [0b01, 0b0001, 0b000001]
[1, 1, 1]

We also cannot replicate this example: https://github.com/python/cpython/blob/master/Lib/encodings/cp866.py#L47-L176

This code will pass, but it is incorrect:

decoding_map.update({
    0x80: 0x0410,  # 0 leading zeros: one leading zero
    0x0081: 0x0411,  # 2 leading zeros, one leading zero
}

We need to explicit mark places where invalid code might be located. And allow only valid code by default.