Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enforce consistent octal, hex, and binary numbers #420

Closed
sobolevn opened this issue Dec 29, 2018 · 11 comments
Closed

Enforce consistent octal, hex, and binary numbers #420

sobolevn opened this issue Dec 29, 2018 · 11 comments
Assignees
Labels
help wanted Extra attention is needed level:starter Good for newcomers pr-rejected rule request Adding a new rule

Comments

@sobolevn
Copy link
Member

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.

@sobolevn sobolevn added help wanted Extra attention is needed level:starter Good for newcomers rule request Adding a new rule labels Dec 29, 2018
@sobolevn sobolevn added this to the Version 0.7.0 milestone Dec 29, 2018
@kxepal
Copy link

kxepal commented Dec 31, 2018

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

@sobolevn
Copy link
Member Author

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

@kxepal
Copy link

kxepal commented Dec 31, 2018

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
Copy link
Member Author

@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
Copy link

kxepal commented Jan 14, 2019

You're welcome! 🍻

@astynax
Copy link
Contributor

astynax commented Mar 5, 2019

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
Copy link
Member Author

sobolevn commented Apr 1, 2019

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

@AndreyErmilov
Copy link

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

@sobolevn
Copy link
Member Author

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

@sobolevn
Copy link
Member Author

sobolevn commented Apr 14, 2019

@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
Copy link
Member Author

sobolevn commented Jul 20, 2019

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.

sobolevn added a commit that referenced this issue Jul 21, 2019
sobolevn added a commit that referenced this issue Jul 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed level:starter Good for newcomers pr-rejected rule request Adding a new rule
Projects
None yet
4 participants