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

Whitespace in slices when there is an open side #33

Closed
warsaw opened this issue Jan 27, 2021 · 6 comments
Closed

Whitespace in slices when there is an open side #33

warsaw opened this issue Jan 27, 2021 · 6 comments

Comments

@warsaw
Copy link
Collaborator

warsaw commented Jan 27, 2021

Black does this, yuck!

-            whitespace = orig_line[:-len(line)]
+            whitespace = orig_line[: -len(line)]
@grantjenks
Copy link
Owner

grantjenks commented Feb 12, 2021

I'm 0.25 on this. Sometimes I like to see an additional set of parens for expressions in slices. Like:

            whitespace = orig_line[:(-len(line))]

@grantjenks
Copy link
Owner

Having looked through a bunch of diffs in the last hour, I've actually come around to Black's formatting here. The added space doesn't hurt.

@warsaw
Copy link
Collaborator Author

warsaw commented Feb 12, 2021

I can live with it, but it goes against PEP 8, IMHO:

However, in a slice the colon acts like a binary operator, and should have equal amounts on either side (treating it as the operator with the lowest priority). In an extended slice, both colons must have the same amount of spacing applied. Exception: when a slice parameter is omitted, the space is omitted:

@MatthewScholefield
Copy link

Personally, I don't think it makes sense because this rule is inconsistent in that it causes spacing to change purely based on the type of expression (expressions are not treated uniformly).

Ie. Each of the following would be a consistent formatting rule:

  • foo[: bar_len] and foo[: len(bar)]
  • foo[:bar_len] and foo[:len(bar)].

But not how it does it right now which is:

  • foo[:bar_len] and foo[: len(bar)].

@grantjenks
Copy link
Owner

Addressing my previous comment -- I realize now that the addition of parens is impossible given Black's constraints. Adding parens would modify the AST which Black forbids to prevent changing semantics.

@warsaw having read the PEP 8 section you quote, I don't see what part black violates here.

@warsaw
Copy link
Collaborator Author

warsaw commented Aug 16, 2021

I think that's fine. Let's close this one as "won't fix".

@warsaw warsaw closed this as completed Aug 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants