module level multiline strings getting mangled into unreadability, forcing code changes

[AvdN]

As a YAML library developer, I have quite a few module level multiline strings:

data = yaml.load("""\
a: 1
b: 2
""")

Black transforms this into

data = yaml.load(
    """\
a: 1
b: 2
"""
)

I can live with the two extra lines, but one wants to have the triple-quotes aligned (as this is not the same string, I understand that this is not done automagically):

data = yaml.load(
    """\
a: 1
b: 2
    """
)

That is of course unacceptable from a readability point of view, so one would tend to align the mapping keys in the document as well:

data = yaml.load(
    """\
    a: 1
    b: 2
    """
)

now for this YAML document that leads to the same data being loaded, but that is not always the case (e.g. not if the document starts with an explicit document marker).

I can provide some mechanism in the library for (auto-) dedenting of the input on calling load, but it seems to me that the transform of a multiline string to the next line as if it doesn't fit, is contrary to why one is using multiline strings in the first place: "so you don't have to cope with long strings\nwith embedded newlines that don't fit\non any reasonably sized line width")

Black should, for correct behavior, only consider the first line of a multi-line strings and check if that (with the preceding assignment and function call) on the line or not, whereas now it seems black takes the rather dumb approach of considering the whole of the multi-line string and then comes to the conclusion that it does not fit on a single line (which cannot really be a surprise), and so uglifies the code by pushing the starting triple quotes to the next line.

---

There is a "workable" alternative, that doesn't get mangled by black:

str_raw = """\
a: 1
b: 2
"""
data = yaml.load(str_raw)

but I rather not have to make code changes in all of the places I have module level strings are used to work around this issue.

[zsol]

Thanks for the thorough analysis and the report. I believe the root cause of this is the same as behind #256 so going to close this out in favor of that