-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Break before slice colon #7332
Break before slice colon #7332
Conversation
Nice! Does this impact our similarity index? How would it look if we intended the right side if the line breaks? |
@@ -91,7 +91,7 @@ impl FormatNodeRule<ExprSlice> for FormatExprSlice { | |||
if !all_simple && lower.is_some() { | |||
space().fmt(f)?; | |||
} | |||
token(":").fmt(f)?; | |||
write!(f, [soft_line_break(), token(":")])?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should move this into the else
branch or we may end up with an unintentional a \n<space>
@@ -155,7 +167,8 @@ d1 = "d"[ # comment | |||
: | |||
] | |||
d2 = "d"[ # comment | |||
1: | |||
1 | |||
: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, this isn't ideal. Do we need to group the line break with the left side so that it only renders if the left expands (or the :
and the right side don't fit on the line)
**Summary** Break slices at the colon first, since the colon is separator with the lowest precedence and we're in a parenthesized context. **Input** ```python section_header_data = byte_array[byte_begin_index + byte_step_index * event_index : byte_begin_index + byte_step_index * (event_index + 1)] ``` **Black** ```python section_header_data = byte_array[ byte_begin_index + byte_step_index * event_index : byte_begin_index + byte_step_index * (event_index + 1) ] ``` **Current formatting** ```python section_header_data = byte_array[ byte_begin_index + byte_step_index * event_index : byte_begin_index + byte_step_index * (event_index + 1) ] ``` **Proposed formatting** ```python section_header_data = byte_array[ byte_begin_index + byte_step_index * event_index : byte_begin_index + byte_step_index * (event_index + 1) ] ``` This is another intentional black deviation, but i find it a clear style improvement. This is consistent with adding a step: ```python section_header_data2 = byte_array[ byte_begin_index + byte_step_index * event_index : byte_begin_index + byte_step_index : section_size ] ``` As-is, this regresses trailing colon comments: **in** ```python c1 = "c"[ 1: # e # f 2 ] ``` **out** ```python c1 = "c"[ 1 : # e # f 2 ] ``` Fixes #7316 **Test Plan** Added the fixtures above.
e5f4163
to
d4cfe1f
Compare
We have decided to not merge this to instead focus on black compatibility instead of adding more deviations |
Summary Break slices at the colon first, since the colon is separator with the lowest precedence and we're in a parenthesized context.
Input
Black
Current formatting
Proposed formatting
This is another intentional black deviation, but i find it a clear style improvement.
This is consistent with adding a step:
As-is, this regresses trailing colon comments:
in
out
main
PR
For the similarity index, this is a regression.
Fixes #7316
Test Plan Added the fixtures above.