black: PEP 604 and line breaks
Describe the style change
Long PEP 604 annotations (X | Y) in function definitions (and probably other contexts) are currently broken into multiple lines without extra indentation. This makes it hard to recognize the arguments in the signature. My suggestion would be to treat those annotations similar to regular bitwise or operators inside type annotations: Indent followup lines and possibly use parentheses.
Examples in the current Black style
def foo(
i: int,
x: Loooooooooooooooooooooooong
| Looooooooooooooooong
| Looooooooooooooooooooong
| Looooooong,
*,
s: str
) -> None:
pass
A practical example (with shorter line width):
def create_medical_record_entries(
context: RequestContext,
db_entries: Iterable[CharlyMedicalRecordEntry]
| Iterable[CharlyLabRecordEntry],
*,
ignore_signs: bool = True
) -> list[MedicalRecordEntry]:
...
Desired style (without extra arguments)
def foo(
x: (
Loooooooooooooooooooooooong
| Looooooooooooooooong
| Looooooooooooooooooooong
| Looooooong
),
) -> None:
pass
Or maybe:
def foo(
x:
Loooooooooooooooooooooooong
| Looooooooooooooooong
| Looooooooooooooooooooong
| Looooooong,
) -> None:
pass
Or:
def foo(
x: Loooooooooooooooooooooooong
| Looooooooooooooooong
| Looooooooooooooooooooong
| Looooooong,
) -> None:
pass
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 15
- Comments: 16 (6 by maintainers)
Current Black line-break is awkward with a short type hinting with a long default value as well:
IMHO the following is better:
It is how it is done without the type annotation.
I really like the (preview) style changes from #3899
That’s essentially option (1) above - it has the advantages of being easy to implement (and indeed implemented), working well with default values, and consistency with variable annotations (though IMO this is a minor concern at most). My favorite style is actually option (3), which omits the parens - but it’s unclear what should happen when there’s a default value.
I propose that we either stick with the parens-using new status quo, or adopt the
nextlineformatting above, and either way close this issue for good before the next style update / major version.Please comment, or react ❤️ for “keep status-quo parens”, or 🚀 for “change and use
nextline”.We’ve begun porting our type annotations to Python 3.10+
|unions, and we have hit this as well. It really decreases readability compared to how Black formatsOptional[T], hiding type information on another line. Here’s a small snippet from a Typer CLI app:@Zeta611’s suggestion is what we were going to propose as well.
After implementing
nextlinein #3930 and seeing diffs on real live code we agreed that it in fact was not an improvement in the majority of cases, so we can close this issue as resolved as of #3899, that resolved this in “style 1” with parentheses.Hey, I see
Release 23.1.0is assigned here, but this update was a bit time ago. Is there any progress? I’m working with some FastAPI project right now, and this issue seems to be the only thing really really stopping me from using Black.Thanks everyone, and especially @jakkdl for making this happen!
@tekumara you can get that automatically by running black with
--previewto enable the fixes from #3899Option 3 looks clearer to me in function annotations, but I don’t know if there should be separate styles for function arguments and other annotations.