This is possibly not a bug, but the results are unexpected and don't really seem to improve readability. However feel free to close if this is actually correct.
Operating system: Fedora 28
Python version: 3.6.5
Black version: 18.5b0
Does also happen on master: yes
Formatting this file uses some extra unexpected new lines:
MULTILINE = """
foo
""".replace("\n", "")
@@ -1,4 +1,6 @@
MULTILINE = """
foo
-""".replace("\n", "")
+""".replace(
+ "\n", ""
+)
Black considers multiline strings as always not fitting a single line (per definition), so it tries to break the line if possible. I agree that in this case the result is sub-optimal. I'll see what I can do to improve this.
@AvdN points out another effect of how black treats multiline strings that are styled like this in #426 (in the case when the string is a parameter to a function call)
A related case is:
textwrap.dedent("""\
Hello, I am
a multiline string used with
a common idiom
""")
We need to fix that, too.
That related case is how I got here. For clarity here, the above:
textwrap.dedent("""\
Hello, I am
a multiline string used with
a common idiom
""")
becomes:
textwrap.dedent(
"""\
Hello, I am
a multiline string used with
a common idiom
"""
)
Amusingly you can of course instead change it to:
s = """\
Hello, I am
a multiline string used with
a common idiom
"""
s = textwrap.dedent(s)
in one fewer lines and which black will accept (and won't churn when this is resolved) - or do the dedent call at the point of use.
What's the status of this one? I've seen this one has been opened around 2018 and evolved quite a bit over the years... if I'm not mistaken it seems black is still screwing up this common & readable pattern:
if __name__ == "__main__":
transform(textwrap.dedent("""
# from random import random
def random():
return 10
a = random()*10
"""))
into something like this:
if __name__ == "__main__":
transform(
textwrap.dedent(
"""
# from random import random
def random():
return 10
a = random()*10
"""
)
)
One of the main reasons to use textwrap.dedent pattern with multiline strings is because "indentation awareness"... But in this case, that sense of indentation will be lost thanks to black... said otherwise, in this particular case black has destroyed the code into something much worse.
Black version: black, version 19.10b0
Python: 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 23 2018, 23:31:17) [MSC v.1916 32 bit (Intel)] on win32
I love black... I really do... but this issue is really nasty... not just because black will breaks code folding completely but also because the output produced by black doesn't make any sense in comparison the original clean version. I find myself adding clauses # fmt: off & # fmt: on more than I should when that shouldn't be case.
I understand none of the maintainers is interested on this issue? I've see both this one and other related ones have been opened for years... question for people who've submitted patches to black before, do you what's the place in the codebase where this is handled?
Thanks.
Ps. Why this important issue hasn't been fixed already? Has it been considered a non-go? Too difficult to handle? I'd like to understand... :)
This is a big pet peeve for me too. There's information about contributing here, if you're interested, @brupelo:
Some quick questions:
I'm trying to get a sense if this issue clears the hurdle mentioned in the contribution README: On the other hand, if your answer is "because I don't like a particular formatting" then you're not ready to embrace Black yet. Such changes are unlikely to get accepted. You can still try but prepare to be disappointed.
I'd be happy to take a stab if someone would be willing to do some hand holding along the way, as I'd be a brand new contributor.
Thanks for your efforts, black is awesome and amazing. 馃挴
The point about 芦liking禄 is dismissive of more serious concerns. Single vs double quotes is an annoying change but mostly irrelevant (it was nice to match the style that the Python REPL outputs, but quote style doesn鈥檛 matter and there is a point that it鈥檚 common to have apostrophe in a string, so :shrug:). But people care about diffs and history, and the developer is the person best situated to decide if this is an extensible list/dict/set that is multiline from the start, or something that can be rewritten by a style program. (One of the worst cases is parameters to the pytest.parametrize decorator that are rewritten to waste screen space without benefit.)
I kept running into this so I decided to spend some time figuring how to fix it. Happy to say I have a branch that should do just that! It's got a new 316 line test file with a bunch of cases (including the ones reported in this and linked issues). However, the code is still messy as I haven't yet taken the time to clean it up: right now it's ~100 new lines dumped into the is_line_short_enough function. I'll post a draft PR in the next day or two after some basic cleanup, just wanted to comment to let others know if they had been thinking of spending time on this.
FWIW, the branch is more of a POC right now and requires more work before it could be mergeable. I have some hacked-together code for bracket tracking, trailing comma handling, etc., which will require some refactoring so I can reuse the existing functions for that (will need help from the black folks on the best approach). There's also more work to do like finishing up draft changes to the black style guide docs & CHANGES.rst looking through the black-primer output to verify the changes and work with the relevant upstreams.
Opened https://github.com/psf/black/pull/1879 with my prototype fix! Would love feedback from folks on the new tests I added and whether the formatting I chose makes sense (AFAIK I included all the examples from this and linked issues).
Most helpful comment
A related case is:
We need to fix that, too.