call-layout
LayoutExplodes a keyword-expressible call carrying more than the inline-argument cap to one keyword argument per line.
Adjacent string literals concatenate at compile time, which makes a long message easy to assemble and easy to lose track of, since the run either overruns a single line or scatters across several with the seams landing wherever the author stopped typing.
gives the run a settled shape by breaking it one literal per line once its joined line overrunscode-line-length, so the seam between one literal and the next falls at a line end, where the eye already looks for it. The same one-entry-per-line reading the layout family applies to calls, signatures, and collections reaches a string run too.A run the enclosing brackets already carry breaks in place, each later literal landing at the indent of the row the run opens on, which is how a call argument, a collection element, and a dict value take the break. A run standing where no bracket holds it, a return value or an assignment's right side among them, gains the parentheses the continuation needs, its literals one indent step in and the closing ) back at the statement's indent.
A run the enclosing call's parentheses already carry breaks in place, each later literal landing at the indent of the row the run opens on rather than gaining a nested pair of its own.
emit(
"the opening clause of this notice "
"and the trailing clause"
)
The rule only ever breaks a run, so a run the author already wrote one literal per line holds that shape whatever its width and a deliberate stack survives rather than being rejoined into a line the next edit would have to break again, a hold that covers a backslash-continued run as readily as a parenthesized one. A run spanning several lines with two literals still sharing one is the shape the rule settles, so it normalizes to one per line whatever the width, the ragged seam being the defect rather than the line count.
A run standing as a body's leading expression stays exactly as written and keeps its line however wide it runs, because parenthesizing it would leave a docstring that no longer reads as one. A run holding a triple-quoted part that spans lines keeps its place for a different reason, wherein moving that part would carry its opening line away from the interior the source pinned. A comment anywhere inside the enclosing pair pins the run as well, the rewrite spanning the pair and having nowhere to put the comment.
Bytes runs and runs mixing an f-string or t-string with a plain literal all break the same way, since each is one implicitly concatenated expression. The break falls between the parts and never inside one, so a replacement field keeps its own text untouched. A run held in a docstring slot and a line no break can bring within budget both reach , which reports the line rather than leaving it for a rule that will not act on it.
| Key | Type | Default | Meaning |
|---|---|---|---|
enabled | bool | true | Toggles the rule on or off. |
The break answers to the top-level code-line-length key, measured from the column the run lands at once
An implicitly concatenated run whose joined line overruns code-line-length wraps in parentheses and takes one literal per line, so the seam between one literal and the next falls at a line end.
message = (
"the opening clause of this notice "
"and the trailing clause"
)
Adjacent bytes literals concatenate the same way adjacent str literals do, so an over-budget bytes run takes the same one-per-line break.
A run standing as a dict key breaks at the entry's own indent, and the entry keeps its key: value line rather than hanging at the :, since the break is what brings the row inside the budget whichever half of the entry carries the run.
A run standing as a dict value breaks at the indent of the entry's own row rather than at the column the value opens at, and the entry keeps its key: value line instead of hanging at the :.
A run standing as a return value carries no bracket of its own, so the break wraps it in parentheses and drops the closing one to the statement's indent.
A completed helper(...) pair ahead of the run opens and closes before it, so the bracket the break answers to is the call's own rather than the nested pair that already shut.
A run the enclosing call's parentheses already carry breaks in place, each later literal landing at the indent of the row the run opens on rather than gaining a nested pair of its own.
A subscript never expands, so its bracket leaves the run on the statement's own row. The run wraps in parentheses rather than breaking in place, since a continuation at the statement's indent would read as the next statement.
A run whose parts mix an f-string with a plain literal breaks between the parts, leaving each replacement field untouched inside the part that carries it.
A run spanning several lines with two literals sharing one normalizes to one literal per line whatever its width, since the ragged boundary is the shape the rule exists to settle.
Adjacent t"..." literals concatenate the way str and bytes literals do, so an over-budget template run takes the same one-per-line break and each replacement field keeps its own text.
A run continued across lines by a backslash carries one literal per line already, so it falls under the same hold a parenthesized stack does and keeps its continuation style.
A comment anywhere inside the pair enclosing a run holds the run at its source shape, because the rewrite spans the pair and would carry the comment off its line.
A run the author already wrote one literal per line holds that shape even though the joined form would fit, so the rule only ever breaks a run and never rejoins one.
A run holding a triple-quoted part that spans lines stays as written, since moving such a part would place its opening line away from the interior the source pinned.
A run standing as a body's leading expression keeps its line however wide it runs, since parenthesizing it would leave a docstring that no longer reads as one.
A run whose joined line clears code-line-length stays on one line, because the break answers to the budget rather than to the presence of a concatenation.
Explodes a keyword-expressible call carrying more than the inline-argument cap to one keyword argument per line.
Splits list, tuple, dict, and set literals into one-entry-per-line layout once they overflow their width, or a dict crosses an entry-count cap.
Names any line still over its governing cap once no reshape can shorten it.
Sheds a grouping parenthesis pair that binds nothing, reflowing the expression onto the line it now fits.
Normalizes function signatures to one line or one parameter per line, gated by line length and inline-parameter count.