Line breaks for boolean expressions makes code less readable

[aklajnert]

Sometimes if the boolean expressions are too long, black seems to break lines in wrong place which makes the or much harder to spot while reading the code.

Black v19.3b0

Playground link

Options

--line-length=60

Input

def test_function():
    return obj.method(arguments=True) or obj.method(arguments=False)


if obj.method(arguments=True) or obj.method(arguments=False):
    pass

Output

def test_function():
    return obj.method(arguments=True) or obj.method(
        arguments=False
    )


if obj.method(arguments=True) or obj.method(
    arguments=False
):
    pass

Expected

I would expect to have each part of or in separate line, similar to the following:

def test_function():
    return (
        obj.method(arguments=True) or
        obj.method(arguments=False)
    )


if (
    obj.method(arguments=True) or
    obj.method(arguments=False)
):
    pass

Another example

If you change return type to tuple, it has much better formatting:

# before
def test_function():
    return (obj.method(arguments=True), obj.method(arguments=False))

# after
def test_function():
    return (
        obj.method(arguments=True),
        obj.method(arguments=False),
    )

[nchammas]

Related issue: #317

I also agree that it's more readable to have lines broken around key operators, which a) makes them easy to spot and b) makes reordering terms easy.

(Regarding the latter point, in VSCode option + ↑ will drag the current line up one, so if you have multiple terms broken up by the boolean expressions between them, reordering the terms is easy.)

def test_function():
    return (
        obj.method(arguments=True)
        or obj.method(arguments=False)
        or obj.anothermethod()  # option + ↑ to drag this up one line
    )

I do prefer a variation on what you propose, as you can see in my example, where the operator is at the start of the line. This is more similar to what @e3krisztian laid out in #317. This makes it easy to scan down the left side and see all the relevant operators or method calls. It's a familiar style for folks who use the fluent-style of programming (see #67), which is common when working with data manipulation libraries like SQLAlchemy, Pandas, and Apache Spark.

All that being said, I wonder how much more room there is to evolve Black's style as the days go by. I imagine at this point it's quite difficult because any non-bugfix changes will likely have a massive impact on existing users, and that will not be acceptable to them.

But, @ambv's closing note on #317 seemed to express some approval of the idea there, so perhaps this one here has some chance of making it.

[felix-hilden]

Your particular example has been discussed more recently and more in depth in #2156, so I'll close this as a duplicate!