Line too long: Long triple-quoted string

[brettcannon]

Describe the bug Adding an = within an f-string that is too long to fit on a line causes Black to undo the work it did to try and make the line fit within the column restrictions

To Reproduce Steps to reproduce the behavior:

1. Take this code:

class Wraps:
    binary_inplace_op.__doc__ = f"""Implement the augmented arithmetic assignment `a {binary_op.operator} b`."""


class NoWrap:
    binary_inplace_op.__doc__ = f"""Implement the augmented arithmetic assignment `a {binary_op.operator}= b`."""

2. Run Black
3. Notice how the line in the Wraps class gets wrapped to try and make the line shorter, while in the NoWrap class the introduction of a = in the f-string undoes the wrapping.

Expected behavior
To see the line with the = in the f-string` still be wrapped since it is now even longer than before.

Environment (please complete the following information):

• Version: 19.10b0
• OS and Python version: CPython 3.8.3, macOS

Does this bug also happen on master?

Yes.

[zsol]

FWIW I don't think that = character is special, it has to do with the length of the string I think: example.

In the original example in OP, the string in Wraps is 73 characters long. + 6 " + 1 f makes it 80, and after indenting two levels it's exactly 88 characters long. NoWrap adds one more character, which makes it impossible to keep the line length under 88, so Black just doesn't even try indenting.

I think this is working as intended. We can have a discussion if this is the right intention or not :)

[JelleZijlstra]

Does it work with --experimental-string-processing?

[brettcannon]

@JelleZijlstra same results.

[ambv]

Yeah, this is not a bug. There's no point putting additional parentheses around things that won't fit anyway. If you split the string into two, you'll see correct behavior. It's a bug that --experimental-string-processing doesn't do this automatically for you though.

[bbugyi200]

@JelleZijlstra @ambv I know I'm late to the party here, but note that --experimental-string-processing (i.e. #1132) does not attempt to improve (or change at all) the way black handles triple-quoted strings.