On 2020-08-14 16:29:18 +1200, dn via Python-list wrote:
> For f-strings/formatted string literals, the most usual form is:
>
> "{" f_expression ["="] ["!" conversion] [":" format_spec] "}"
>
> Remembering that this is BNF, see the space separating the closing-brace
> from anything preceding it
No. I see a space before the quote before the closing brace.
> - how else would we separate the components to
> comprehend?
>
> Returning to Python:
>
> >>> one = 1 # is the loneliest number...
> >>> f'{ one }'
> '1'
> >>> f'{ one:03 }'
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> ValueError: Unknown format code '\x20' for object of type 'int'
> >>> f'{ one:03}'
> '001'
>
> Notice the presence/absence of the final space.
>
> >>> pi = 3.14159 # better to import math
> >>> f'{ pi!r:10 }'
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> ValueError: Unknown format code '\x20' for object of type 'str'
> >>> f'{ pi!r:10}'
> '3.14159 '
> >>> f'{ pi!r }'
> File "<stdin>", line 1
> SyntaxError: f-string: expecting '}'
> >>> f'{ pi!r}'
> '3.14159'
>
> So, the f-string will work if the braces include only an expression
> surrounded by spaces. However, if one adds a conversion or
> format-specification, that final space becomes a no-no. Eh what!
That doesn't surprise me. The "!" and ":" split the replacement field
into three parts.
The f_expression is just a subset of normal python expressions, which
allow whitespace, so
f"{pi+1}"
f"{pi + 1}"
f"{ pi + 1 }"
f"{ pi + 1 !r}"
f"{ pi + 1 :f}"
are all valid.
The conversion consists only of a single character ("a", "r", or "s"),
anything else is invalid.
The format_spec is everything between the colon and the closing brace.
Syntactically, that can contain spaces. However, that is passed to the
object's __format__() method, and for builtin objects that method
doesn't know what to do with a space (you could implement it for your
own objects, though).
> To be fair, the 'book of words' does say: "A replacement field ends with a
> closing curly bracket '}'.". No mention of whitespace. No mention that a
> replacement field consisting only of an f_expression, will be treated
> differently by allowing a space.
>
> Version 3.8 introduced the "=" short-cut:
>
> >>> f"{ foo = }" # preserves whitespace
> " foo = 'bar'"
>
> Note the comment! Yet, the manual's examples continue:
>
> >>> line = "The mill's closed"
> >>> f"{line = }"
> 'line = "The mill\'s closed"'
> >>> f"{line = :20}"
> "line = The mill's closed "
>
> Hey, why does this second example dispense with the braces-internal spaces?
It doesn't. The space is still there - before the colon.
> Should the closing brace be considered part of a conversion or
> format-specification?
No.
> The space (I'd like to add) cannot be considered part of a conversion
> or format-specification (see BNF, see text of web.ref)!
But it is part of the format specification:
format_spec ::= (literal_char | NULL | replacement_field)*
literal_char ::= <any code point except "{", "}" or NULL>
Note: *any* code point except "{", "}" or NULL. So that includes space.
(BTW, what is NULL? U+0000 doesn't make much sense here (and is usually
written NUL (with one L) and an empty string is not a code point.)
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | h...@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
-- https://mail.python.org/mailman/listinfo/python-list
