string_processing: Extra parentheses added even when string isn't split

[wookie184]

Describe the bug
With preview style, a long f-string where the only spaces are in the expression bit has parentheses added even though it isn't split over lines. For example:

f(
    f'longstringwithnospacesinthestringbitbutwithspacesintheformattyfstringbithere{ 1 }',
)

becomes

f(
    (
        f"longstringwithnospacesinthestringbitbutwithspacesintheformattyfstringbithere{ 1 }"
    ),
)

I would instead expect it not to have changed. See on black playground

I noticed it also seems to occur with normal strings where the split is very near the start or end

f(
    "l ongstringwithnospacesinthestringbitbutwithspacesintheformattyfstringbitherelollol",
)

becomes

f(
    (
        "l ongstringwithnospacesinthestringbitbutwithspacesintheformattyfstringbitherelollol"
    ),
)

See on black playground
Version
Black 23.1a1, with --preview

[ownchoice]

I'm not sure if it's exactly the same problem but looks like it is, so I'm gonna share my case here instead of opening a new issue.

Describe the bug

Black turns some variable definition with strings as value into multiline assignments and adds parentheses, but doesn't seem to follow a pattern for doing so. Doesn't happen with some longer strings or variables names.

To Reproduce

Using this input:

test1: str = "https://{subdomain}.api.server.com/media/animals/v4/photos/{animal_id}"

test2: str = "https://{subdomain}.api.server.com/media/animals/v4/photos/animal/{animal_id}"

test3 = "https://{subdomain}.api.server.com/media/animals/v4/photos/animal/{animal_id}"

test4 = "https://{subdomain}.api.server.com/media/animals/v4/photos/animal/longer/{animal_id}"

test5: str = "https://{subdomain}.api.server.com/media/animals/v4/photos/animal/something/else/{animal_id}"

test6: str = "https://{subdomain}.api.server.com/media/animals/v4/photos/animal/{animal_id}/test"

test7 = "https://{subdomain}.api.server.com/media/animals/v4/photos/animal/{animal_id}/test"

test7 = "https://{subdomain}.api.server.com/media/animals/v4/photos/animal/{animal_id}/test2"

test8: str = "https://{subdomain}.api.server.com/media/animals/v4/photos/animal/{animal_id}/lorem"

Format it with Black and you'll get the following output:

test1: str = "https://{subdomain}.api.server.com/media/animals/v4/photos/{animal_id}"

test2: str = (
    "https://{subdomain}.api.server.com/media/animals/v4/photos/animal/{animal_id}"
)

test3 = "https://{subdomain}.api.server.com/media/animals/v4/photos/animal/{animal_id}"

test4 = "https://{subdomain}.api.server.com/media/animals/v4/photos/animal/longer/{animal_id}"

test5: str = "https://{subdomain}.api.server.com/media/animals/v4/photos/animal/something/else/{animal_id}"

test6: str = (
    "https://{subdomain}.api.server.com/media/animals/v4/photos/animal/{animal_id}/test"
)

test7 = (
    "https://{subdomain}.api.server.com/media/animals/v4/photos/animal/{animal_id}/test"
)

test7 = "https://{subdomain}.api.server.com/media/animals/v4/photos/animal/{animal_id}/test2"

test8: str = "https://{subdomain}.api.server.com/media/animals/v4/photos/animal/{animal_id}/lorem"

What I expected to happen

I can't figure out why would Black randomly use multiline strings when it seems unnecesary.

It's not because of line length.

Black doesn't add parentheses to longer string and/or longer variable names, so I'm at a loss about what is causing it to only happen with some strings.

May be related to issue #232

Things I have done already

1. Updated Black's version to the newest release (pip install -U black)
2. Tested this bug using the online formatter at https://black.vercel.app/?version=main
3. Tested this bug using the online formatter at https://black.vercel.app/?version=stable
4. Tested using a virtualenv with the lastest Black version on it

Environment

Env 1:

• https://black.vercel.app/?version=main

Env 2:

• Black's version: 22.12.0 (latest)
• Python version: Python 3.11.0
• OS version: Windows 11 Pro 10.0.22621 Build 22621

[ichard26]

@ownchoice this is a different issue. Black doesn't wrap long string assignments if it would still violate the line length limit even after being exploded AFAIK. Maybe we should for consistency...