Skip to content

Commit 18f4d04

Browse files
davepeckwarsaw
andauthored
PEP 750: restrict support for Template + str addition (#4395)
* Remove support for Template/str addition. * Update PEP to conform to python/steering-council#289 Co-authored-by: Barry Warsaw <[email protected]>
1 parent e7e5af4 commit 18f4d04

File tree

1 file changed

+39
-28
lines changed

1 file changed

+39
-28
lines changed

peps/pep-0750.rst

Lines changed: 39 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -394,37 +394,44 @@ Template String Concatenation
394394
-----------------------------
395395

396396
Template strings support explicit concatenation using ``+``. Concatenation is
397-
supported for two ``Template`` instances as well as for a ``Template`` instance
398-
and a ``str``:
397+
supported for two ``Template`` instances via ``Template.__add__()``:
399398

400399
.. code-block:: python
401400
402401
name = "World"
403-
template = t"{name}"
404402
405-
assert isinstance(t"Hello " + template, Template)
406-
assert (t"Hello " + template).strings == ("Hello ", "")
407-
assert (t"Hello " + template).interpolations[0].value == "World"
403+
assert isinstance(t"Hello " + t"{name}", Template)
404+
assert (t"Hello " + t"{name}").strings == ("Hello ", "")
405+
assert (t"Hello " + t"{name}").values[0] == "World"
408406
409-
assert isinstance("Hello " + template, Template)
410-
assert ("Hello " + template).strings == ("Hello ", "")
411-
assert ("Hello " + template).interpolations[0].value == "World"
407+
Implicit concatenation of two template string literals is also supported:
412408

413-
Concatenation of templates is "viral": the concatenation of a ``Template`` and
414-
a ``str`` always results in a ``Template`` instance.
409+
.. code-block:: python
410+
411+
name = "World"
412+
assert isinstance(t"Hello " t"{name}", Template)
413+
assert (t"Hello " t"{name}").strings == ("Hello ", "")
414+
assert (t"Hello " t"{name}").values[0] == "World"
415+
416+
Both implicit and explicit concatenation of ``Template`` and ``str`` is
417+
prohibited. This is because it is ambiguous whether the ``str`` should be
418+
treated as a static string part or as an interpolation.
415419

416-
Python's implicit concatenation syntax is also supported. The following code
417-
will work as expected:
420+
To combine a ``Template`` and a ``str``, developers must explicitly decide how
421+
to treat the ``str``. If the ``str`` is intended to be a static string part,
422+
it should be wrapped in a ``Template``. If the ``str`` is intended to be an
423+
interpolation value, it should be wrapped in an ``Interpolation`` and
424+
passed to the ``Template`` constructor. For example:
418425

419426
.. code-block:: python
420427
421428
name = "World"
422-
assert (t"Hello " t"World").strings == ("Hello World",)
423-
assert ("Hello " t"World").strings == ("Hello World",)
424429
425-
The ``Template`` type supports the ``__add__()`` and ``__radd__()`` methods
426-
between two ``Template`` instances and between a ``Template`` instance and a
427-
``str``.
430+
# Treat `name` as a static string part
431+
template = t"Hello " + Template(name)
432+
433+
# Treat `name` as an interpolation
434+
template = t"Hello " + Template(Interpolation(name, "name"))
428435
429436
430437
Template and Interpolation Equality
@@ -1349,11 +1356,12 @@ Developers who need to obtain the original template string literal can always
13491356
use ``inspect.getsource()`` or similar tools.
13501357

13511358

1352-
Disallowing String Concatenation
1353-
--------------------------------
1359+
Disallowing Template Concatenation
1360+
----------------------------------
13541361

1355-
Earlier versions of this PEP proposed that template strings should not support
1356-
concatenation. This was rejected in favor of allowing concatenation.
1362+
Earlier versions of this PEP proposed that ``Template`` instances should not
1363+
support concatenation. This was rejected in favor of allowing concatenating
1364+
multiple ``Template`` instances.
13571365

13581366
There are reasonable arguments in favor of rejecting one or all forms of
13591367
concatenation: namely, that it cuts off a class of potential bugs, particularly
@@ -1367,13 +1375,16 @@ return a type that supported concatenation.
13671375

13681376
In the end, we decided that the surprise to developers of a new string type
13691377
*not* supporting concatenation was likely to be greater than the theoretical
1370-
harm caused by supporting it. (Developers concatenate f-strings all the time,
1371-
after all, and while we are sure there are cases where this introduces bugs,
1372-
it's not clear that those bugs outweigh the benefits of supporting concatenation.)
1378+
harm caused by supporting it.
1379+
1380+
While concatenation of two ``Templates`` is supported by this PEP, concatenation
1381+
of a ``Template`` and a ``str`` is not supported. This is because it is
1382+
ambiguous whether ``str`` should be treated as a static string or an
1383+
interpolation. Developers must wrap the ``str`` in a ``Template`` instance
1384+
before concatenating it with another ``Template``, as described above.
13731385

1374-
While concatenation is supported, we expect that code that uses template strings
1375-
will more commonly build up larger templates through nesting and composition
1376-
rather than concatenation.
1386+
We expect that code that uses template strings will more commonly build up
1387+
larger templates through nesting and composition rather than concatenation.
13771388

13781389

13791390
Arbitrary Conversion Values

0 commit comments

Comments
 (0)