You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I wasn't sure if I should submit a style or bug report for this (or should it be a question?). I'm sorry if I picked the wrong template.
Black implements a neat little optimization for constants and names to avoid wrapping them in parentheses when the parenthesized expression exceeds the line length.
In the following code, Black omits parenthesizing the "exceeds parenthesized" cases because the code exceeds the line length when adding and when omitting the optional parentheses, which is why it favors omitting the parentheses. Except, for attributes...
I implemented the same behavior in Ruff and incorrectly assumed that it would apply to all expressions that cannot be split further (which includes non-fluent attribute chains). I guess the bug / style suggestion / question is: Should blacked code omit parentheses around attribute chains if they exceed the configured line length regardless if they're parenthesized or not, to be consistent with other unsplittable expressions?
Edit: Somewhat related. Black breaks the left before parenthesizing the right for constants, names, and non-fluent attribute chains.
state[
"event_queue_longpoll_timeout_seconds"
] =settings.EVENT_QUEUE_LONGPOLL_TIMEOUT_SECONDS# Instead of, at least without preview modestate["event_queue_longpoll_timeout_seconds"] = (
settings.EVENT_QUEUE_LONGPOLL_TIMEOUT_SECONDS
)
but it already breaks the right before the left for binary expressions (and other splittable expressions)
It's probably too late to use this as a real argument, considering that this changes with preview style, but handling non-fluent attribute chains identical to constants and names when parenthesizing would make their handling more consistent.
The text was updated successfully, but these errors were encountered:
We probably should actually split these attribute chains, like this:
I think that would be ideal. I haven't yet had time to closely look into what it would mean to split attribute chains (how does it affect all other formatting rules). I would love to collaborate on defining a new style together. At least, after getting the preview style implemented. Black's formatting is so good and has many hidden gems you only realize when paying attention. It will take me a while to get up to parity. I appreciate all the hard work you've put into defining the style guide.
Note that Black currently goes a little out of its way to forbid that kind of split. Even in fluent interfaces, the first attribute access currently remains unsplit. So will require a little bit of figuring out what the right rule is :-)
(Coincidentally, I was just looking at fluent interface formatting to fix some other undesirable splitting caused by experimental string processing and #67 (comment) and #3998).
I wasn't sure if I should submit a style or bug report for this (or should it be a question?). I'm sorry if I picked the wrong template.
Black implements a neat little optimization for constants and names to avoid wrapping them in parentheses when the parenthesized expression exceeds the line length.
In the following code, Black omits parenthesizing the "exceeds parenthesized" cases because the code exceeds the line length when adding and when omitting the optional parentheses, which is why it favors omitting the parentheses. Except, for attributes...
I implemented the same behavior in Ruff and incorrectly assumed that it would apply to all expressions that cannot be split further (which includes non-fluent attribute chains). I guess the bug / style suggestion / question is: Should blacked code omit parentheses around attribute chains if they exceed the configured line length regardless if they're parenthesized or not, to be consistent with other unsplittable expressions?
Edit: Somewhat related. Black breaks the left before parenthesizing the right for constants, names, and non-fluent attribute chains.
but it already breaks the right before the left for binary expressions (and other splittable expressions)
It's probably too late to use this as a real argument, considering that this changes with preview style, but handling non-fluent attribute chains identical to constants and names when parenthesizing would make their handling more consistent.
The text was updated successfully, but these errors were encountered: