Unexpected whitespace handling in f-string !r

[dimaqq]

Bug report

The handling of whitespace around the argument in literal string interpolation (f-string) is unexpected when a conversion specifier (e.g. !r) is applied.

Consider

f"{None}"  # OK
f"{ None }"  # OK
f"{None!r}"  # OK
f"{ None!r }"  # SyntaxError

# details
f"{ None!r}  # OK
f"{None !r}  # OK
f"{None!r }  # SyntaxError

PEP-498 states:

Leading and trailing whitespace in expressions is ignored
For ease of readability, leading and trailing whitespace in expressions is ignored. This is a by-product of enclosing the expression in parentheses before evaluation.

I suppose that the text above may be technically accurate, but is misleading to common folk:
In the example above, None is enclosed in parentheses (None) but not None!r.

There are no mentions of whitespace in the rest of the PEP.

Formal reproducer:

> python3.11 -c 'print(f"{ None!r }")'
  File "<string>", line 1
    print(f"{ None!r }")
                       ^
SyntaxError: f-string: expecting '}'

Your environment

• CPython versions tested on: 3.8, 3.9, 3.10, 3.11a2, 3.11a7
• Operating system and architecture: Linux, MacOS

[dimaqq]

cc @pablogsal b/c 2022 PSL f-string grammar

[dimaqq]

cc @ericvsmith who continues to gather feefback

[ericvsmith]

The space in the statements with a syntax error above is not part of the expression, it's part of the conversion specifier. I do not want to weaken the parsing here, and I do not consider this a bug. I suppose we could improve the error message, and a quick search doesn't show a test for this. There is a test for a space in f'{3! s}', which could be expanded to also raise an error for a trailing space.

[AA-Turner]

Marking as a feature request for a better error message or better documentation, given a core developer has noted this is not a bug.

A

[dimaqq]

A side note on multi-line f-strings.
Current rules only allow these:

f"""{
  None
}"""
c = f"""{
  None
!r}"""

but not this:

d = f"""{
  None!r
}"""

I feel that the developer experience is subpar here.
At the same time, I feel that conversion specifiers are a bit of an afterthought anyway 🤷🏿

[ericvsmith]

I can assure you that conversion specifiers were not an afterthought. They come from PEP 3101 (16 years ago), and were present from the beginning.

If the error message were "Unknown conversion specifier 'r\n'", would that not make it clear enough what the problem is?

[dimaqq]

I apologize, I must have misread the spec and I was under the impression that {repr(a)} was preferred over {a!r} and {str(a)} over {a!s}.

[ericvsmith]

The spec has no preference: either way works. It’s just a style thing.