Black Fails to Format Single String Longer Than Line Length Limit

[kennytrytek-wf]

Describe the bug
A Python file containing a single string assignment longer than the line length limit is not reformatted.

To Reproduce
Take long_line.py:

long = "This is a long line that is longer than 88 characters. I expect Black to shorten this line length."

Run Black:

$ black ./long_line.py 
All done! ✨ 🍰 ✨
1 file left unchanged.

Expected behavior
I expect black to shorten the line length to less than the length limit. One possible solution is to break on the <line length limit minus 1> character and parenthesize if it is not already inside parentheses:

long = (
    "This is a long line that is longer than 88 characters. I expect Black to shorten "
    "this line length."
)

Environment (please complete the following information):

$ black --version
black, version 20.8b1

OS: macOS Catalina 10.15.6

$ python --version
Python 3.8.5

Does this bug also happen on master?
Yes

Additional context
None

[JelleZijlstra]

This is currently implemented under the hidden --experimental-string-processing flag, which we'll hopefully be able to enable soon.

[kennytrytek-wf]

Confirmed that this works as expected.

$ black ./long_line.py --experimental-string-processing
reformatted long_line.py
All done! ✨ 🍰 ✨
1 file reformatted.

long = (
    "This is a long line that is longer than 88 characters. I expect Black to shorten"
    " this line length."
)

[Delvio]

If I wanted to configure this flag on VScode should I just add --experimental-string-processing as an argument?

[ichard26]

@Delvio I believe so IIRC.

[Delvio]

@ichard26 for some reason it's not working on my end, this is the config I have for the black arguments

"python.formatting.blackArgs": [
"--line-length",
"79",
"--experimental-string-processing"
],

Any guidance that you can provide me will be much appreciated.

[ichard26]

@Delvio what version of Black is installed in your environment? 20.8b1 is the only version with --experimental-string-processing support

[Delvio]

@ichard26 I was using an older version but I now upgraded to black==20.8b1, the issue persists.

I even closed VSCode and opened it again (we never know)

[ichard26]

Ok, here's a non-exhaustive list of things to do / check:

1. Make sure the environment containing the updated Black is the one used by Visual Studio Code (look in the status bar for this)
2. Check that you don't have workspace settings overriding your Black configuration (if you used the user settings)

Also it would be nice if I could get your Python Log output (Output Tab of pop-up panel and select the 'Python' output) as it may tell me why it ain't working :( I'm looking for something like this (I took this from my Visual Studio Code instance that has Black working correctly):

> ~/programming/oss/pre-commit-autoupdater/env/bin/python ~/.vscode/extensions/ms-python.python-2020.12.424452561/pythonFiles/pyvsc-run-isolated.py black --line-length 79 --experimental-string-processing --diff --quiet ~/programming/oss/pre-commit-autoupdater/t.py

[Delvio]

@ichard26 To avoid conflicts between workspace settings I have the same for both user and workspace settings,

This is the log that I see from the python output:

> ~/Development/rd/env/bin/python ~/.vscode/extensions/ms-python.python-2020.12.424452561/pythonFiles/pyvsc-run-isolated.py pip --version
> ~/Development/rd/env/bin/black --line-length 79 --experimental-string-processing --diff --quiet ~/Development/rd/bck-rdmas/config/settings/base.py
cwd: ~/Development/rd/bck-rdmas
> ~/Development/rd/env/bin/flake8 --max-line-length=79 --format=%(row)d,%(col)d,%(code).1s,%(code)s:%(text)s ~/Development/rd/bck-rdmas/config/settings/base.py
cwd: ~/Development/rd/bck-rdmas
##########Linting Output - flake8##########
5,1,I,I003:isort expected 1 blank line in imports, found 0
123,80,E,E501:line too long (90 > 79 characters)
276,80,E,E501:line too long (84 > 79 characters)
309,80,E,E501:line too long (82 > 79 characters)
310,80,E,E501:line too long (82 > 79 characters)
344,80,E,E501:line too long (150 > 79 characters)

[tabbea]

For anyone who still hasn't been able to use this, I have gotten this working on my VSCode with the following settings.json

"python.formatting.blackArgs": [
    "--line-length=80",
    "--experimental-string-processing"
],

Or using the gui:

I think that the line length argument may be an issue with many people inputting the actual number as an additional argument after the flag rather than using the = operator.

For example, see this stackoverflow answer.

[avcourt]

If wanting to specify --experimental-string-processing in pyproject.toml use this format:

[tool.black]
experimental-string-processing = true

[Anon-Exploiter]

@ichard26 for some reason it's not working on my end, this is the config I have for the black arguments

"python.formatting.blackArgs": [
"--line-length",
"79",
"--experimental-string-processing"
],

Any guidance that you can provide me will be much appreciated.

Strange, it works fine for me. Here's my settings.json section.

    "python.formatting.provider": "black",
    "python.formatting.blackArgs": [
        "--line-length",
        "70",
        "--experimental-string-processing"
    ],

--

Now the output:

Before:

After:

[Anon-Exploiter]

One more QA test case:

When there are no spaces in the string, black doesn't work and doesn't break the string in multiple lines. @Delvio can you confirm if you didn't have any spaces in the string you were testing?

test_string = "ttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt"

another_string = "test test test test test test test test test test test test test test test test test test test test test test test test test test test test test "

Before:

Output:

When you add spaces in the string before -- it works:

--

@JelleZijlstra can you please confirm if this is intended 😅

[dariocurr]

When there are no spaces in the string, black doesn't work and doesn't break the string in multiple lines

Yes I confirm

[ichard26]

Yes, experimental string processing will not break a string if has no spaces in it. FWIW, there is a proposal to allow breaking on escaped \n as they make sense as the split point: #1467. I'd be personally happy with such a change, but I haven't looked into it quite yet.

[FantasticMrFux]

Hello would somebody help me how I can integrate this into vim? So executing :Black will be use the flag --experimental-string-processing.
Thanks

[zffocussss]

the below settings work .

/usr/local/bin/black --version
black, version 21.9b0

"python.formatting.provider": "black",
 "python.formatting.blackArgs": [
        "--line-length",
        "80",
        "--experimental-string-processing"
    ],
  "python.formatting.blackPath": "/usr/local/bin/black",

[FantasticMrFux]

Thanks for your answer but where should I put this? Somewhere in my vimrc?

[anirudhsundar]

Hello would somebody help me how I can integrate this into vim? So executing :Black will be use the flag --experimental-string-processing. Thanks

@FantasticMrFux Did you ever find the answer to this?

[Mausy5043]

$ black --version
black, 22.10.0 (compiled: yes)
Python (CPython) 3.10.11

Use of the switch --experimental-string-processing is nolonger supported and returns:

<string>:13: Deprecated: `experimental string processing` has been included in `preview` and deprecated. Use `preview` instead.

Using the --preview switch, apart from not knowing what else is being changed, does not result in strings getting processed correctly.

[pheetah]

I have the same issue with @Mausy5043 , when I try to format with black -l 80 --preview it works for code lines but not for strings (I have a string has 416 characters left untouched on formatting), when I use black --experimental-string-processing I get the same error.

[simonprovost]

Same as @Mausy5043 and @pheetah ! Docstrings are not taken into account. Can provide example if needed!|

Tried --preview and the deprecated --experimental-string-processing.

[Dionysus326]

Same as @pheetah
The long string did not work at all (not in docstring) even when I tried either --preview or --experimental-string-processing.
I am using black version 22.3.0.

[CodeCubeNeo]

Any updates on this? Why is the string not getting formatted?

[JelleZijlstra]

This is enabled in the --preview mode, which is expected to become the default in the first release in 2024.

[CodeCubeNeo]

--preview does not split the string. It leaves the file as is

[JelleZijlstra]

% black --preview -c 'long = "This is a long line that is longer than 88 characters. I expect Black to shorten this line length."'
long = (
    "This is a long line that is longer than 88 characters. I expect Black to shorten"
    " this line length."
)

[JelleZijlstra]

If you find a case where it doesn't work, please open a new issue instead of posting on this old and closed one.