751 lines
24 KiB
Plaintext
751 lines
24 KiB
Plaintext
PEP: 498
|
||
Title: Literal String Interpolation
|
||
Version: $Revision$
|
||
Last-Modified: $Date$
|
||
Author: Eric V. Smith <eric@trueblade.com>
|
||
Status: Draft
|
||
Type: Standards Track
|
||
Content-Type: text/x-rst
|
||
Created: 01-Aug-2015
|
||
Python-Version: 3.6
|
||
Post-History: 07-Aug-2015, 30-Aug-2015
|
||
|
||
Abstract
|
||
========
|
||
|
||
Python supports multiple ways to format text strings. These include
|
||
%-formatting [#]_, ``str.format()`` [#]_, and ``string.Template``
|
||
[#]_. Each of these methods have their advantages, but in addition
|
||
have disadvantages that make them cumbersome to use in practice. This
|
||
PEP proposed to add a new string formatting mechanism: Literal String
|
||
Interpolation. In this PEP, such strings will be refered to as
|
||
"f-strings", taken from the leading character used to denote such
|
||
strings, and standing for "formatted strings".
|
||
|
||
This PEP does not propose to remove or deprecate any of the existing
|
||
string formatting mechanisms.
|
||
|
||
f-strings provide a way to embed expressions inside string literals,
|
||
using a minimal syntax. It should be noted that an f-string is really
|
||
an expression evaluated at run time, not a constant value. In Python
|
||
source code, an f-string is a literal string, prefixed with 'f', that
|
||
contains expressions inside braces. The expressions are replaced with
|
||
their values. Some examples are::
|
||
|
||
>>> import datetime
|
||
>>> name = 'Fred'
|
||
>>> age = 50
|
||
>>> anniversary = datetime.date(1991, 10, 12)
|
||
>>> f'My name is {name}, my age next year is {age+1}, my anniversary is {anniversary:%A, %B %d, %Y}.'
|
||
'My name is Fred, my age next year is 51, my anniversary is Saturday, October 12, 1991.'
|
||
>>> f'He said his name is {name!r}.'
|
||
"He said his name is 'Fred'."
|
||
|
||
A similar feature was proposed in PEP 215 [#]_. PEP 215 proposed to
|
||
support a subset of Python expressions, and did not support the
|
||
type-specific string formatting (the ``__format__()`` method) which
|
||
was introduced with PEP 3101 [#]_.
|
||
|
||
Rationale
|
||
=========
|
||
|
||
This PEP is driven by the desire to have a simpler way to format
|
||
strings in Python. The existing ways of formatting are either error
|
||
prone, inflexible, or cumbersome.
|
||
|
||
%-formatting is limited as to the types it supports. Only ints, strs,
|
||
and doubles can be formatted. All other types are either not
|
||
supported, or converted to one of these types before formatting. In
|
||
addition, there's a well-known trap where a single value is passed::
|
||
|
||
>>> msg = 'disk failure'
|
||
>>> 'error: %s' % msg
|
||
'error: disk failure'
|
||
|
||
But if msg were ever to be a tuple, the same code would fail::
|
||
|
||
>>> msg = ('disk failure', 32)
|
||
>>> 'error: %s' % msg
|
||
Traceback (most recent call last):
|
||
File "<stdin>", line 1, in <module>
|
||
TypeError: not all arguments converted during string formatting
|
||
|
||
To be defensive, the following code should be used::
|
||
|
||
>>> 'error: %s' % (msg,)
|
||
"error: ('disk failure', 32)"
|
||
|
||
``str.format()`` was added to address some of these problems with
|
||
%-formatting. In particular, it uses normal function call syntax (and
|
||
therefor supports multiple parameters) and it is extensible through
|
||
the ``__format__()`` method on the object being converted to a
|
||
string. See PEP-3101 for a detailed rationale. This PEP reuses much of
|
||
the ``str.format()`` syntax and machinery, in order to provide
|
||
continuity with an existing Python string formatting mechanism.
|
||
|
||
However, ``str.format()`` is not without its issues. Chief among them
|
||
is its verbosity. For example, the text ``value`` is repeated here::
|
||
|
||
>>> value = 4 * 20
|
||
>>> 'The value is {value}.'.format(value=value)
|
||
'The value is 80.'
|
||
|
||
Even in its simplest form, there is a bit of boilerplate, and the
|
||
value that's inserted into the placeholder is sometimes far removed
|
||
from where the placeholder is situated::
|
||
|
||
>>> 'The value is {}.'.format(value)
|
||
'The value is 80.'
|
||
|
||
With an f-string, this becomes::
|
||
|
||
>>> f'The value is {value}.'
|
||
'The value is 80.'
|
||
|
||
f-strings provide a concise, readable way to include the value of
|
||
Python expressions inside strings.
|
||
|
||
In this sense, ``string.Template`` and %-formatting have similar
|
||
shortcomings to ``str.format()``, but also support fewer formatting
|
||
options. In particular, they do not support the ``__format__``
|
||
protocol, so that there is no way to control how a specific object is
|
||
converted to a string, nor can it be extended to additional types that
|
||
want to control how they are converted to strings (such as ``Decimal``
|
||
and ``datetime``). This example is not possible with
|
||
``string.Template``::
|
||
|
||
>>> value = 1234
|
||
>>> f'input={value:#0.6x}'
|
||
'input=0x04d2'
|
||
|
||
And neither %-formatting nor ``string.Template`` can control
|
||
formatting such as::
|
||
|
||
>>> date = datetime.date(1991, 10, 12)
|
||
>>> f'{date} was on a {date:%A}'
|
||
'1991-10-12 was on a Saturday'
|
||
|
||
No use of globals() or locals()
|
||
-------------------------------
|
||
|
||
In the discussions on python-dev [#]_, a number of solutions where
|
||
presented that used locals() and globals() or their equivalents. All
|
||
of these have various problems. Among these are referencing variables
|
||
that are not otherwise used in a closure. Consider::
|
||
|
||
>>> def outer(x):
|
||
... def inner():
|
||
... return 'x={x}'.format_map(locals())
|
||
... return inner
|
||
...
|
||
>>> outer(42)()
|
||
Traceback (most recent call last):
|
||
File "<stdin>", line 1, in <module>
|
||
File "<stdin>", line 3, in inner
|
||
KeyError: 'x'
|
||
|
||
This returns an error because the compiler has not added a reference
|
||
to x inside the closure. You need to manually add a reference to x in
|
||
order for this to work::
|
||
|
||
>>> def outer(x):
|
||
... def inner():
|
||
... x
|
||
... return 'x={x}'.format_map(locals())
|
||
... return inner
|
||
...
|
||
>>> outer(42)()
|
||
'x=42'
|
||
|
||
In addition, using locals() or globals() introduces an information
|
||
leak. A called routine that has access to the callers locals() or
|
||
globals() has access to far more information than needed to do the
|
||
string interpolation.
|
||
|
||
Guido stated [#]_ that any solution to better string interpolation
|
||
would not use locals() or globals().
|
||
|
||
Specification
|
||
=============
|
||
|
||
In source code, f-strings are string literals that are prefixed by the
|
||
letter 'f'. 'f' may be combined with 'r', in either order, to produce
|
||
raw f-string literals. 'f' may not be combined with 'b': there are no
|
||
binary f-strings. 'f' may also be combined with 'u', in either order,
|
||
although adding 'u' has no effect.
|
||
|
||
f-strings are parsed in to literals and expressions. Expressions
|
||
appear within curly braces '{' and '}. The parts of the string outside
|
||
of braces are literals. The expressions are evaluated, formatted with
|
||
the existing __format__ protocol, then the results are concatenated
|
||
together with the string literals. While scanning the string for
|
||
expressions, any doubled braces '{{' or '}}' are replaced by the
|
||
corresponding single brace. Doubled opening braces do not signify the
|
||
start of an expression.
|
||
|
||
Following the expression, an optional type conversion may be
|
||
specified. The allowed conversions are ``'!s'``, ``'!r'``, or
|
||
``'!a'``. These are treated the same as in ``str.format()``: ``'!s'``
|
||
calls ``str()`` on the expression, ``'!r'`` calls ``repr()`` on the
|
||
expression, and ``'!a'`` calls ``ascii()`` on the expression. These
|
||
conversions are applied before the call to ``__format__``. The only
|
||
reason to use ``'!s'`` is if you want to specify a format specifier
|
||
that applies to ``str``, not to the type of the expression.
|
||
|
||
Similar to ``str.format()``, optional format specifiers maybe be
|
||
included inside the f-string, separated from the expression (or the
|
||
type conversion, if specified) by a colon. If a format specifier is
|
||
not provied, an empty string is used.
|
||
|
||
So, an f-string looks like::
|
||
|
||
f ' <text> { <expression> <optional !s, !r, or !a> <optional : format specifier> } text ... '
|
||
|
||
The resulting expression's ``__format__`` method is called with the
|
||
format specifier. The resulting value is used when building the value
|
||
of the f-string.
|
||
|
||
Expressions cannot contain ``':'`` or ``'!'`` outside of strings or
|
||
parens, brackets, or braces. The exception is that the ``'!='``
|
||
operator is allowed as a special case.
|
||
|
||
Escape sequences
|
||
----------------
|
||
|
||
Scanning an f-string for expressions happens after escape sequences
|
||
are decoded. Because ``hex(ord('{')) == 0x7b``, the f-string
|
||
``f'\\u007b4*10}'`` is decoded to ``f'{4*10}'``, which evaluates as
|
||
the integer 40::
|
||
|
||
>>> f'\u007b4*10}'
|
||
'40'
|
||
>>> f'\x7b4*10}'
|
||
'40'
|
||
>>> f'\x7b4*10\N{RIGHT CURLY BRACKET}'
|
||
'40'
|
||
|
||
These examples aren't generally useful, they're just to show that
|
||
escape sequences are processed before f-strings are parsed for
|
||
expressions.
|
||
|
||
Code equivalence
|
||
----------------
|
||
|
||
The exact code used to implement f-strings is not specified. However,
|
||
it is guaranteed that any embedded value that is converted to a string
|
||
will use that value's ``__format__`` method. This is the same
|
||
mechanism that ``str.format()`` uses to convert values to strings.
|
||
|
||
For example, this code::
|
||
|
||
f'abc{expr1:spec1}{expr2!r:spec2}def{expr3:!s}ghi'
|
||
|
||
Might be be evaluated as::
|
||
|
||
''.join(['abc', expr1.__format__(spec1), repr(expr2).__format__(spec2), 'def', str(spec3).__format__(''), 'ghi'])
|
||
|
||
Expression evaluation
|
||
---------------------
|
||
|
||
The expressions that are extracted from the string are evaluated in
|
||
the context where the f-string appeared. This means the expression has
|
||
full access to local and global variables. Any valid Python expression
|
||
can be used, including function and method calls.
|
||
|
||
Because the f-strings are evaluated where the string appears in the
|
||
source code, there is no additional expressiveness available with
|
||
f-strings. There are also no additional security concerns: you could
|
||
have also just written the same expression, not inside of an
|
||
f-string::
|
||
|
||
>>> def foo():
|
||
... return 20
|
||
...
|
||
>>> f'result={foo()}'
|
||
'result=20'
|
||
|
||
Is equivalent to::
|
||
|
||
>>> 'result=' + str(foo())
|
||
'result=20'
|
||
|
||
After stripping leading and trailing whitespace (see below), the
|
||
expression is parsed with the equivalent of ``ast.parse(expression,
|
||
'<fstring>', 'eval')`` [#]_. Note that this restricts the expression:
|
||
it cannot contain any newlines, for example::
|
||
|
||
>>> x = 0
|
||
>>> f'''{x
|
||
... +1}'''
|
||
File "<fstring>", line 2
|
||
+1
|
||
^
|
||
SyntaxError: invalid syntax
|
||
|
||
But note that this works, since the newline is removed from the
|
||
string, and the spaces in front of the ``'1'`` are allowed in an
|
||
expression::
|
||
|
||
>>> f'{x+\
|
||
... 1}'
|
||
'2'
|
||
|
||
Format specifiers
|
||
-----------------
|
||
|
||
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}.{precision}}'
|
||
'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.
|
||
|
||
Concatenating strings
|
||
---------------------
|
||
|
||
Adjacent f-strings and regular strings are concatenated. Regular
|
||
strings are concatenated at compile time, and f-strings are
|
||
concatenated at run time. For example, the expression::
|
||
|
||
>>> x = 10
|
||
>>> y = 'hi'
|
||
>>> 'a' 'b' f'{x}' '{c}' f'str<{y:^4}>' 'd' 'e'
|
||
|
||
yields the value::
|
||
|
||
'ab10{c}str< hi >de'
|
||
|
||
While the exact method of this run time concatenation is unspecified,
|
||
the above code might evaluate to::
|
||
|
||
''.join(['ab', x.__format__(''), '{c}', 'str<', y.__format__('^4'), 'de'])
|
||
|
||
Error handling
|
||
--------------
|
||
|
||
Either compile time or run time errors can occur when processing
|
||
f-strings. Compile time errors are limited to those errors that can be
|
||
detected when scanning an f-string. These errors all raise
|
||
``SyntaxError``.
|
||
|
||
Unmatched braces::
|
||
|
||
>>> f'x={x'
|
||
File "<stdin>", line 1
|
||
SyntaxError: missing '}' in format string expression
|
||
|
||
Invalid expressions::
|
||
|
||
>>> f'x={!x}'
|
||
File "<fstring>", line 1
|
||
!x
|
||
^
|
||
SyntaxError: invalid syntax
|
||
|
||
Run time errors occur when evaluating the expressions inside an
|
||
f-string. Note that an f-string can be evaluated multiple times, and
|
||
work sometimes and raise an error at other times::
|
||
|
||
>>> d = {0:10, 1:20}
|
||
>>> for i in range(3):
|
||
... print(f'{i}:{d[i]}')
|
||
...
|
||
0:10
|
||
1:20
|
||
Traceback (most recent call last):
|
||
File "<stdin>", line 2, in <module>
|
||
KeyError: 2
|
||
|
||
or::
|
||
|
||
>>> for x in (32, 100, 'fifty'):
|
||
... print(f'x = {x:+3}')
|
||
...
|
||
'x = +32'
|
||
'x = +100'
|
||
Traceback (most recent call last):
|
||
File "<stdin>", line 2, in <module>
|
||
ValueError: Sign not allowed in string format specifier
|
||
|
||
Leading and trailing whitespace in expressions is skipped
|
||
---------------------------------------------------------
|
||
|
||
For ease of readability, leading and trailing whitespace in
|
||
expressions is ignored.
|
||
|
||
Evaluation order of expressions
|
||
-------------------------------
|
||
|
||
The expressions in an f-string are evaluated in left-to-right
|
||
order. This is detectable only if the expressions have side effects::
|
||
|
||
>>> def fn(l, incr):
|
||
... result = l[0]
|
||
... l[0] += incr
|
||
... return result
|
||
...
|
||
>>> lst = [0]
|
||
>>> f'{fn(lst,2)} {fn(lst,3)}'
|
||
'0 2'
|
||
>>> f'{fn(lst,2)} {fn(lst,3)}'
|
||
'5 7'
|
||
>>> lst
|
||
[10]
|
||
|
||
Discussion
|
||
==========
|
||
|
||
python-ideas discussion
|
||
-----------------------
|
||
|
||
Most of the discussions on python-ideas [#]_ focused on three issues:
|
||
|
||
- How to denote f-strings,
|
||
- How to specify the location of expressions in f-strings, and
|
||
- Whether to allow full Python expressions.
|
||
|
||
How to denote f-strings
|
||
***********************
|
||
|
||
Because the compiler must be involved in evaluating the expressions
|
||
contained in the interpolated strings, there must be some way to
|
||
denote to the compiler which strings should be evaluated. This PEP
|
||
chose a leading ``'f'`` character preceeding the string literal. This
|
||
is similar to how ``'b'`` and ``'r'`` prefixes change the meaning of
|
||
the string itself, at compile time. Other prefixes were suggested,
|
||
such as ``'i'``. No option seemed better than the other, so ``'f'``
|
||
was chosen.
|
||
|
||
Another option was to support special functions, known to the
|
||
compiler, such as ``Format()``. This seems like too much magic for
|
||
Python: not only is there a chance for collision with existing
|
||
identifiers, the PEP author feels that it's better to signify the
|
||
magic with a string prefix character.
|
||
|
||
How to specify the location of expressions in f-strings
|
||
*******************************************************
|
||
|
||
This PEP supports the same syntax as ``str.format()`` for
|
||
distinguishing replacement text inside strings: expressions are
|
||
contained inside braces. There were other options suggested, such as
|
||
``string.Template``'s ``$identifier`` or ``${expression}``.
|
||
|
||
While ``$identifier`` is no doubt more familiar to shell scripters and
|
||
users of some other languages, in Python ``str.format()`` is heavily
|
||
used. A quick search of Python's standard library shows only a handful
|
||
of uses of ``string.Template``, but hundreds of uses of
|
||
``str.format()``.
|
||
|
||
Another proposed alternative was to have the substituted text between
|
||
``\\{`` and ``}`` or between ``\\{`` and ``\\}``. While this syntax
|
||
would probably be desirable if all string literals were to support
|
||
interpolation, this PEP only supports strings that are already marked
|
||
with the leading ``'f'``. As such, the PEP is using unadorned braces
|
||
to denoted substituted text, in order to leverage end user familiarity
|
||
with ``str.format()``.
|
||
|
||
Supporting full Python expressions
|
||
**********************************
|
||
|
||
Many people on the python-ideas discussion wanted support for either
|
||
only single identifiers, or a limited subset of Python expressions
|
||
(such as the subset supported by ``str.format()``). This PEP supports
|
||
full Python expressions inside the braces. Without full expressions,
|
||
some desirable usage would be cumbersome. For example::
|
||
|
||
>>> f'Column={col_idx+1}'
|
||
>>> f'number of items: {len(items)}'
|
||
|
||
would become::
|
||
|
||
>>> col_number = col_idx+1
|
||
>>> f'Column={col_number}'
|
||
>>> n_items = len(items)
|
||
>>> f'number of items: {n_items}'
|
||
|
||
While it's true that very ugly expressions could be included in the
|
||
f-strings, this PEP takes the position that such uses should be
|
||
addressed in a linter or code review::
|
||
|
||
>>> f'mapping is { {a:b for (a, b) in ((1, 2), (3, 4))}}'
|
||
'mapping is {1: 2, 3: 4}'
|
||
|
||
Similar support in other languages
|
||
----------------------------------
|
||
|
||
Wikipedia has a good discussion of string interpolation in other
|
||
programming languages [#]_. This feature is implemented in many
|
||
languages, with a variety of syntaxes and restrictions.
|
||
|
||
Differences between f-string and str.format expressions
|
||
-------------------------------------------------------
|
||
|
||
There is one small difference between the limited expressions allowed
|
||
in ``str.format()`` and the full expressions allowed inside
|
||
f-strings. The difference is in how index lookups are performed. In
|
||
``str.format()``, index values that do not look like numbers are
|
||
converted to strings::
|
||
|
||
>>> d = {'a': 10, 'b': 20}
|
||
>>> 'a={d[a]}'.format(d=d)
|
||
'a=10'
|
||
|
||
Notice that the index value is converted to the string ``'a'`` when it
|
||
is looked up in the dict.
|
||
|
||
However, in f-strings, you would need to use a literal for the value
|
||
of ``'a'``::
|
||
|
||
>>> f'a={d["a"]}'
|
||
'a=10'
|
||
|
||
This difference is required because otherwise you would not be able to
|
||
use variables as index values::
|
||
|
||
>>> a = 'b'
|
||
>>> f'a={d[a]}'
|
||
'a=20'
|
||
|
||
See [#]_ for a further discussion. It was this observation that led to
|
||
full Python expressions being supported in f-strings.
|
||
|
||
Furthermore, the limited expressions that ``str.format()`` understands
|
||
need not be valid Python expressions. For example::
|
||
|
||
>>> '{i[";]}'.format(i={'";':4})
|
||
'4'
|
||
|
||
For this reason, the str.format() "expression parser" is not suitable
|
||
for use when implementing f-strings.
|
||
|
||
Triple-quoted f-strings
|
||
-----------------------
|
||
|
||
Triple quoted f-strings are allowed. These strings are parsed just as
|
||
normal triple-quoted strings are. After parsing, the normal f-string
|
||
logic is applied, and ``__format__()`` on each value is called.
|
||
|
||
Raw f-strings
|
||
-------------
|
||
|
||
Raw and f-strings may be combined. For example they could be used to
|
||
build up regular expressions::
|
||
|
||
>>> header = 'Subject'
|
||
>>> fr'{header}:\s+'
|
||
'Subject:\\s+'
|
||
|
||
In addition, raw f-strings may be combined with triple-quoted strings.
|
||
|
||
No binary f-strings
|
||
-------------------
|
||
|
||
For the same reason that we don't support ``bytes.format()``, you may
|
||
not combine ``'f'`` with ``'b'`` string literals. The primary problem
|
||
is that an object's ``__format__()`` method may return Unicode data that
|
||
is not compatible with a bytes string.
|
||
|
||
Binary f-strings would first require a solution for
|
||
``bytes.format()``. This idea has been proposed in the past, most
|
||
recently in PEP 461 [#]_. The discussions of such a feature usually
|
||
suggest either
|
||
|
||
- adding a method such as ``__bformat__()`` so an object can control
|
||
how it is converted to bytes, or
|
||
|
||
- having ``bytes.format()`` not be as general purpose or extensible
|
||
as ``str.format()``.
|
||
|
||
Both of these remain as options in the future, if such functionality
|
||
is desired.
|
||
|
||
``!s``, ``!r``, and ``!a`` are redundant
|
||
----------------------------------------
|
||
|
||
The ``!s``, ``!r``, and ``!a`` conversions are not strictly
|
||
required. Because arbitrary expressions are allowed inside the
|
||
f-strings, this code::
|
||
|
||
>>> a = 'some string'
|
||
>>> f'{a!r}'
|
||
"'some string'"
|
||
|
||
Is identical to::
|
||
|
||
>>> f'{repr(a)}'
|
||
"'some string'"
|
||
|
||
Similarly, ``!s`` can be replaced by calls to ``str()`` and ``!a`` by
|
||
calls to ``ascii()``.
|
||
|
||
However, ``!s``, ``!r``, and ``!a`` are supported by this PEP in order
|
||
to minimize the differences with ``str.format()``. ``!s``, ``!r``, and
|
||
``!a`` are required in ``str.format()`` because it does not allow the
|
||
execution of arbitrary expressions.
|
||
|
||
Lambdas inside expressions
|
||
--------------------------
|
||
|
||
Because lambdas use the ``':'`` character, they cannot appear outside
|
||
of parenthesis in an expression. The colon is interpreted as the start
|
||
of the format specifier, which means the start of the lambda
|
||
expression is seen and is syntactically invalid. As there's no
|
||
practical use for a plain lambda in an f-string expression, this is
|
||
not seen as much of a limitation.
|
||
|
||
If you feel you must use lambdas, they may be used inside of parens::
|
||
|
||
>>> f'{(lambda x: x*2)(3)}'
|
||
'6'
|
||
|
||
Examples from Python's source code
|
||
==================================
|
||
|
||
Here are some examples from Python source code that currently use
|
||
``str.format()``, and how they would look with f-strings. This PEP
|
||
does not recommend wholesale converting to f-strings, these are just
|
||
examples of real-world usages of ``str.format()`` and how they'd look
|
||
if written from scratch using f-strings.
|
||
|
||
``Lib/asyncio/locks.py``::
|
||
|
||
extra = '{},waiters:{}'.format(extra, len(self._waiters))
|
||
extra = f'{extra},waiters:{len(self._waiters)}'
|
||
|
||
``Lib/configparser.py``::
|
||
|
||
message.append(" [line {0:2d}]".format(lineno))
|
||
message.append(f" [line {lineno:2d}]")
|
||
|
||
``Tools/clinic/clinic.py``::
|
||
|
||
methoddef_name = "{}_METHODDEF".format(c_basename.upper())
|
||
methoddef_name = f"{c_basename.upper()}_METHODDEF"
|
||
|
||
``python-config.py``::
|
||
|
||
print("Usage: {0} [{1}]".format(sys.argv[0], '|'.join('--'+opt for opt in valid_opts)), file=sys.stderr)
|
||
print(f"Usage: {sys.argv[0]} [{'|'.join('--'+opt for opt in valid_opts)}]", file=sys.stderr)
|
||
|
||
Implementation limitations
|
||
==========================
|
||
|
||
Maximum of 255 expressions
|
||
--------------------------
|
||
|
||
Due to a CPython limit with the number of parameters to a function, an
|
||
f-string may not contain more that 255 expressions. This includes
|
||
expressions inside format specifiers. So this code would count as
|
||
having 2 expressions::
|
||
|
||
f'{x:.{width}}'
|
||
|
||
The same expression used multiple times
|
||
---------------------------------------
|
||
|
||
Every expression in an f-string is evaluated exactly once for each
|
||
time it appears in the f-string. However, when the same expression
|
||
appears more than once in an f-string, it's undefined which result
|
||
will be used in the resulting string value. This only matters for
|
||
expressions with side effects.
|
||
|
||
For purposes of this section, two expressions are the same if they
|
||
have the exact same literal text defining them. For example, ``'{i}'``
|
||
and ``'{i}'`` are the same expression, but ``'{i}'`` and ``'{i }'``
|
||
are not, due to the extra space in the second expression.
|
||
|
||
For example, given::
|
||
|
||
>>> def fn(lst):
|
||
... lst[0] += 1
|
||
... return lst[0]
|
||
...
|
||
>>> lst=[0]
|
||
>>> f'{fn(lst)} {fn(lst)}'
|
||
'1 2'
|
||
|
||
The resulting f-string might have the value ``'1 2'``, ``'2 2'``,
|
||
``'1 1'``, or even ``'2 1'``.
|
||
|
||
However::
|
||
|
||
>>> lst=[0]
|
||
>>> f'{fn(lst)} { fn(lst)}'
|
||
'1 2'
|
||
|
||
This f-string will always have the value ``'1 2'``. This is due to the
|
||
two expressions not being the same: the space in the second example
|
||
makes the two expressions distinct.
|
||
|
||
This restriction is in place in order to allow for a possible future
|
||
extension allowing translated strings, wherein the expression
|
||
substitutions would be identified by their text representations in the
|
||
f-strings.
|
||
|
||
References
|
||
==========
|
||
|
||
.. [#] %-formatting
|
||
(https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting)
|
||
|
||
.. [#] str.format
|
||
(https://docs.python.org/3/library/string.html#formatstrings)
|
||
|
||
.. [#] string.Template documentation
|
||
(https://docs.python.org/3/library/string.html#template-strings)
|
||
|
||
.. [#] PEP 215: String Interpolation
|
||
(https://www.python.org/dev/peps/pep-0215/)
|
||
|
||
.. [#] PEP 3101: Advanced String Formatting
|
||
(https://www.python.org/dev/peps/pep-3101/)
|
||
|
||
.. [#] Formatting using locals() and globals()
|
||
(https://mail.python.org/pipermail/python-ideas/2015-July/034671.html)
|
||
|
||
.. [#] Avoid locals() and globals()
|
||
(https://mail.python.org/pipermail/python-ideas/2015-July/034701.html)
|
||
|
||
.. [#] str.format_map() documentation
|
||
(https://docs.python.org/3/library/stdtypes.html#str.format_map)
|
||
|
||
.. [#] Format string syntax
|
||
(https://docs.python.org/3/library/string.html#format-string-syntax)
|
||
|
||
.. [#] ast.parse() documentation
|
||
(https://docs.python.org/3/library/ast.html#ast.parse)
|
||
|
||
.. [#] Start of python-ideas discussion
|
||
(https://mail.python.org/pipermail/python-ideas/2015-July/034657.html)
|
||
|
||
.. [#] Wikipedia article on string interpolation
|
||
(https://en.wikipedia.org/wiki/String_interpolation)
|
||
|
||
.. [#] Differences in str.format() and f-string expressions
|
||
(https://mail.python.org/pipermail/python-ideas/2015-July/034726.html)
|
||
|
||
.. [#] PEP 461 rejects bytes.format()
|
||
(https://www.python.org/dev/peps/pep-0461/#proposed-variations)
|
||
|
||
Copyright
|
||
=========
|
||
|
||
This document has been placed in the public domain.
|
||
|
||
|
||
..
|
||
Local Variables:
|
||
mode: indented-text
|
||
indent-tabs-mode: nil
|
||
sentence-end-double-space: t
|
||
fill-column: 70
|
||
coding: utf-8
|
||
End:
|