Small typos. Added section about nested expressions inside format specifiers.
This commit is contained in:
parent
908470b0aa
commit
acf7aa34da
14
pep-0498.txt
14
pep-0498.txt
|
@ -229,7 +229,17 @@ Is equivalent to::
|
|||
Format specifiers
|
||||
-----------------
|
||||
|
||||
Format specifiers are not interpreted by the f-string parser. Just as
|
||||
Format specifiers may also contain evaluated expressions. This allows
|
||||
code such as::
|
||||
|
||||
>>> width = 10
|
||||
>>> precision = 4
|
||||
>>> value = decimal.Decimal('12.34567')
|
||||
>>> f'result: {value:{width}.{prevision}}'
|
||||
'result: 12.35'
|
||||
|
||||
Once expressions in a format specifier are evaluated (if necessary),
|
||||
format specifiers are not interpreted by the f-string evaluator. Just as
|
||||
in str.format(), they are merely passed in to the __format__() method
|
||||
of the object being formatted.
|
||||
|
||||
|
@ -325,7 +335,7 @@ Discussion
|
|||
Most of the discussions on python-ideas [#]_ focused on a few issues:
|
||||
|
||||
- Whether to allow full Python expressions.
|
||||
- How to designate f-strings, and how specify the locaton of
|
||||
- How to designate f-strings, and how to specify the location of
|
||||
expressions in them.
|
||||
- How to concatenate adjacent strings and f-strings.
|
||||
|
||||
|
|
Loading…
Reference in New Issue