Hug closing } when f-string expression has a format specifier

[MichaReiser]

Summary

This PR changes how we format f-string expressions with a format specifier.

Before:

• triple-quoted f- or t-strings with a format specifier were always formatted onto a single line
• single-quoted f- or t-strings could break over multiple lines even when they had format specifiers. The format specifier was separated by a newline + indent from the closing }. This is now invalid syntax under Python 3.13.4.

  f"testeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee{
      a:.3f
  }moreeeeeeeeeeeeeeeeeetest"  

This PR changes two address the invalid syntax and make single and triple quoted strings more consisent:

• f- or t-string elements with a format specifier now hug the closing }. This ensures that the formatter doesn't introduce a now invalid line break after the format specifier.

  f"testeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee{
      a:.3f}moreeeeeeeeeeeeeeeeeetest"  

• Remove the restriction that triple-quoted f- or t-strings can't use the multiline layout if they have a format specifier. This isn't required to fix the invalid syntax BUT it fixes an issue where the formatter requires two passes to correctly format comments nested inside an interpolated format specifier:

  f"""{foo
     :a{
       a # more
      # comment
     }
  }"""

  which before this PR gets formatted to:

  f"""{foo:a{a}
  }"""  # more
      # comment

  which is fairly different from the source. I think making this change should be fine, if this PR makes it into the minor release tomorrow.

I considered if we should always keep elements with a format specifier flat. However, this gets very tricky if the format specifier is already formatted over multiple lines and contains comments (see the triple-quoted case above). That's why I opted to allow them and making the behavior consistent between single and triple quoted strings.

Fixes #18672
Fixes #18632

Note, this PR doesn't change the parser / lexer

Test Plan

Updated / added tests

[MichaReiser]

This example is a syntax error for a single quoted string, but it's perfectly fine for a triple quoted string

[github-actions]

ruff-ecosystem results

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

[github-actions]

mypy_primer results

No ecosystem changes detected ✅

[ntBre]

This makes sense to me, for what it's worth. It definitely makes sense to wait for Dhruv's review, just wanted to take a quick look too in case it helped.

[ntBre]

Is this empty branch part of the TODO above?

[MichaReiser]

Lol no, that's just me moving stuff around and forgetting to delete it (and clippy not telling me)

[MichaReiser]

@ntBre for the changelog (assuming this makes it in). We could probably write something like this

Ruff now formats multiline f-strings with format-specifiers differently because of a change to CPython's grammar. Before, Ruff formatted the interpolation expression like so:

f"This is some long string {
    x:d
} that is formatted across multiple lines"  

The line break after the :d format specifier is now a syntax error with Python 3.13.4 or newer. That's why Ruff now formats the f-string like so:

f"This is some long string {
    x:d} that is formatted across multiple lines"  

[ntBre]

Thanks! I'll add it to the blog post too. There's no real rush on getting the release out from my side, so I think we can wait until this is ready.

[dhruvmanila]

Looks great! Thank you for the quick fix!

[dhruvmanila]

I'm guessing the example mentioned in the comment is specifically to target the format_spec.is_none case and not the trailing comment case. And, as the latter case is going to be removed, we don't really need to provide an example for that here.

[MichaReiser]

The example is for the format_spec.is_some case. It will be removed in my next PR.

I mainly provided it because I found it helpful to reason about all the changes i've been making. I think I keep it, considering that I already have a PR that removes it again.

[dhruvmanila]

• Remove the restriction that triple-quoted f- or t-strings can't use the multiline layout if they have a format specifier. This isn't required to fix the invalid syntax BUT it fixes an issue where the formatter requires two passes to correctly format comments nested inside an interpolated format specifier:

Yeah, I think I mainly did this because the newline for a triple-quoted f-string is a newline character in the literal string and not an actual newline, so that didn't account for the fact that the f-string is multiline. For example, the following is not a multiline f-string:

aaaaaaaaaaa = f"""asaaaaaaaaaaaaaaaa {aaaaaaaaaaaa + bbbbbbbbbbbb + ccccccccccccccc + dddddddd:.3f
} cccccccccc"""

But, it does create inconsistent behavior between triple-quoted and single-quoted f-string which you've noticed. One might argue that is not really an inconsistent behavior as it does follow what we stated regarding when the expression could be broken down i.e., only when the user already has a multiline f-string.

In reality, I guess this shouldn't affect too many users as newlines in format spec should be rare enough especially now that it's a syntax error. So, I'm fine with this change.

[MichaReiser]

Yeah, I think I mainly did this because the newline for a triple-quoted f-string is a newline character in the literal string and not an actual newline, so that didn't account for the fact that the f-string is multiline. For example, the following is not a multiline f-string:

I learned this the hard way when working on this PR 😅. Thanks for adding tests for it.

In reality, I guess this should affect too many users as newlines in format spec should be rare enough especially now that it's a syntax error. So, I'm fine with this change.

Yeah, that was my thinking too and seems to be confirmed by our ecosyste checks.

[MichaReiser]

@ntBre I'll merge this to main, considering that we plan to do the minor release today.