Avoid emitting multi-line f-string elements before Python 3.12

[charliermarsh]

Summary

See: #24355 (comment). Prior to Python 3.12, we need to avoid emitting formatted expressions that span multiple lines in non-triple quoted f-strings.

[astral-sh-bot]

ruff-ecosystem results

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

[charliermarsh]

This is actually invalid on Python 3.11, but the input is already invalid in this case, so I think it's within the bounds of the formatter contract?

[MichaReiser]

I'll review on Tuesday. What's the underlying issue here. Is it that the formatter sometimes formats an interpolation over multiple lines if the f-string contains another multiline interpolation?

[charliermarsh]

Is it that the formatter sometimes formats an interpolation over multiple lines if the f-string contains another multiline interpolation?

Yeah that's right. So I'm unclear if we actually consider this a bug, because I think the code has to be syntactically invalid already in order for this to trigger? In other words, we're introducing another syntax error, but the code was already invalid in another interpolation.

[MichaReiser]

Yeah. I guess it does make it worse. I was mainly curious to understand how rigorous we need to be (e.g. can a triple quoted f-string that's nested in a single quoted f-string contain newlines?)

[charliermarsh]

Thinking about it more, I'm sort of inclined to just treat this as a wontfix. I don't know that it's worth the time / concern / complexity.

[dylwil3]

This warning in the formatter tests seems to implicitly say it's okay to have syntax errors if they were also present in the source:

ruff/crates/ruff_python_formatter/tests/fixtures.rs

Lines 494 to 497 in ee90846

	let sub = SubDiagnostic::new(
	SubDiagnosticSeverity::Warning,
	"Only accept new syntax errors if they are also present in the input. \
	The formatter should not introduce syntax errors.",

So I think wontfix makes sense. (Are we even technically adding a new syntax error? Or just making the existing one "worse"?)

[MichaReiser]

I'm fine either way and agree that I don't consider this a bug, but not introducing more syntax errors seems preferable, and the added complexity is limited.

Thank you