Suggestion: Line wrap .method(... the same as operators like +

[mentalisttraceur]

I have a suggestion - not sure if this is the best place for it, but here goes:

Consider the following input file:

def foo():
    return my_first_really_long_variable_name + my_other_really_long_variable_name_extra_long
def bar():
    return "foo bar qux alp this is a lot of {} in a long {}".format(something, otherthing)

Currently, black -l79 makes the following choices:

def foo():
    return (
        my_first_really_long_variable_name
        + my_other_really_long_variable_name_extra_long
    )


def bar():
    return "foo bar qux alp this is a lot of {} in a long {}".format(
        something, otherthing
    )

I propose that it instead do the following:

def bar():
    return (
        "foo bar qux alp this is a lot of {} in a long {}"
        .format(something, otherthing)
    )

I think that this has several benefits, and I think all the arguments in favor of line breaking in front of an operator like + instead of after apply here.

When I'm looking over code, I find that the former is more readable because it puts the relationship between the things clearer keeps my eyes from having to do as long of a sweep right followed by the eye-movement equivalent of a carriage return.

(This is only a subtly annoying movement when we're used to tuning it out, but it is less ergonomic for the eyes in general, and is also more acutely felt by people with myopia - the most common cause of myopia is an elongation of the eyeball/eyesocket in one directly, which can be physically felt the more severe it gets, as a slight pressure/discomfort sensation that "sweeps" across somewhere inside one's head the further one's eyes swivel in their eye sockets.)

In general I find that this leads to less lines being "jaggedly" outside of the comfortable circle of visual field focus/detail that it is most ergonomic for the eye to stay within for each movement while scanning.

This is especially prominent when going over code quickly - skimming/scanning to refresh my memory or find something - because in those cases I don't have to do a rigorous, meticulous, character-by-character parse.

TL;DR: Having the method call at the start of the line puts the operation, rather than the operands, at the beginning of the visual line, which I've found is the most useful piece of information to have first, and in my experience leads to more visually ergonomic code.

[mentalisttraceur]

To be clear, I am happy to spend the time to make and then polish up a pull request to implement this, if that is desired.

[mentalisttraceur]

I realize that this may be contrary to previously stated reasoning, but at least in my experience, this trade-off isn't actually as bad as it might initially seem. Some years ago, I felt the same way, but gradually optimizing for readability led me here.

Nowadays, given the need to manually line-break and the choice of how, this is how I do it:

my_thing.some_other_thing
.some_operation(arg1, arg2)

and I think it looks weird because we're not used to it, but conceptually/logically/functionally, how is that different from this?

my_thing.some_other_thing
+ some_expression

[mentalisttraceur]

(Sorry for the close/open noise, and for the multiple comments.)

[ambv]

Sorry for the late reply here. Currently your suggested change would make too many changes in projects that already adopted Black and we will not be able to justify this. This is especially true given the discussion on #67. I guess, you can think about it like this: having a single method call detached from the object looks unnatural. While Black is doing its best to keep your line length as you specify it, it does not consider line length trumping all the other rules of formatting it applies.