Black: Black doesn't format expressions inside f-strings

[mxr]

Operating system: macOS 10.13.6
Python version: 3.7.0
Black version: 18.9b0
Does also happen on master: yes

---

Given this example

prefix = "foo"
print(f"{ prefix        }.bar")

I was expecting black to trim the whitespace inside the f-string braces, but black leaves the file as-is.

Is this a bug or expected?

[zsol]

This is an unfortunate side effect of how the AST encodes f-strings :( It would be awesome if black would understand expressions inside f-strings, but that's not the case today.

[ambv]

This is not handled currently because:

• lib2to3 handles f-strings like regular strings; and
• users probably expect a different set of formatting rules within the braces.

In particular, we cannot use newlines inside the braces and we probably should minimize the amount of whitespace compared to regular code.

[janosh]

The title makes this issue a little hard to find. Something like "black not formatting expressions inside f-strings" would make it easier.

[ambv]

This is a design problem. Should we enforce the same style for expressions in f-strings as we do outside of them? In particular, spaces around operators come to mind.

[vpoulailleau]

I came here to write the same kind of issue :wink: BTW, thanks so much for black, this is a great tool!

To my mind, yes the formatting should be the same inside and outside an f-string. But at least, PEP 8 should be respected: "Use your own judgment; however, never use more than one space, and always have the same amount of whitespace on both sides of a binary operator"

Especially when applied to:

x = f"{3  +      5}"

[ericvsmith]

Two points:

1. I've tried on multiple occasions to make CPython use the grammar to parse f-strings, but it's complicated. Maybe the new PEG parser will help here, but I'm not optimistic. I really should write up a description of the problem someday. Basically it's a lexer problem, not a parser problem, but I'm not sure where the PEG parser draws the line. Now that PEP 617 has been accepted I'll dig into it deeper.

2. With the "f-string debugging" feature (a name I do not love), whitespace becomes significant between the expression and before and after the equal sign, so you'd need to be aware of that. Hopefully if the first point is addressed you might get some help here.
   ```>>> x='foo'

   f'{x=}'
   "x='foo'"
   f'{x = }'
   "x = 'foo'"
   ```

I think the significant whitespace here is perhaps too clever, but it solved a design problem.