Use fully spelled-out attribute names for conv and expr.

Author: davepeck

peps/pep-0750.rst

@@ -199,17 +199,17 @@ Like ``Template``, it is a new class found in the ``string.templatelib`` module:
 
     class Interpolation:
         value: object
-        expr: str
-        conv: Literal["a", "r", "s"] | None
+        expression: str
+        conversion: Literal["a", "r", "s"] | None
         format_spec: str
 
-        __match_args__ = ("value", "expr", "conv", "format_spec")
+        __match_args__ = ("value", "expression", "conversion", "format_spec")
 
         def __new__(
             cls,
             value: object,
-            expr: str,
-            conv: Literal["a", "r", "s"] | None = None,
+            expression: str,
+            conversion: Literal["a", "r", "s"] | None = None,
             format_spec: str = "",
         ):
             ...
@@ -225,20 +225,21 @@ The ``value`` attribute is the evaluated result of the interpolation:
     template = t"Hello {name}"
     assert template.interpolations[0].value == "World"
 
-The ``expr`` attribute is the *original text* of the interpolation:
+The ``expression`` attribute is the *original text* of the interpolation:
 
 .. code-block:: python
 
     name = "World"
     template = t"Hello {name}"
-    assert template.interpolations[0].expr == "name"
+    assert template.interpolations[0].expression == "name"
 
-We expect that the ``expr`` attribute will not be used in most template processing
-code. It is provided for completeness and for use in debugging and introspection.
-See both the `Common Patterns Seen in Processing Templates`_ section and the
-`Examples`_ section for more information on how to process template strings.
+We expect that the ``expression`` attribute will not be used in most template 
+processing code. It is provided for completeness and for use in debugging and 
+introspection. See both the `Common Patterns Seen in Processing Templates`_ 
+section and the `Examples`_ section for more information on how to process 
+template strings.
 
-The ``conv`` attribute is the :ref:`optional conversion <python:formatstrings>`
+The ``conversion`` attribute is the :ref:`optional conversion <python:formatstrings>`
 to be used, one of ``r``, ``s``, and ``a``, corresponding to ``repr()``,
 ``str()``, and ``ascii()`` conversions. As with f-strings, no other conversions
 are supported:
@@ -247,9 +248,9 @@ are supported:
 
     name = "World"
     template = t"Hello {name!r}"
-    assert template.interpolations[0].conv == "r"
+    assert template.interpolations[0].conversion == "r"
 
-If no conversion is provided, ``conv`` is ``None``.
+If no conversion is provided, ``conversion`` is ``None``.
 
 The ``format_spec`` attribute is the :ref:`format specification <python:formatspec>`.
 As with f-strings, this is an arbitrary string that defines how to present the value:
@@ -276,7 +277,7 @@ string (``""``). This matches the ``format_spec`` parameter of Python's
 :func:`python:format` built-in.
 
 Unlike f-strings, it is up to code that processes the template to determine how to
-interpret the ``conv`` and ``format_spec`` attributes.
+interpret the ``conversion`` and ``format_spec`` attributes.
 Such code is not required to use these attributes, but when present they should
 be respected, and to the extent possible match the behavior of f-strings.
 It would be surprising if, for example, a template string that uses ``{value:.2f}``
@@ -405,21 +406,21 @@ The debug specifier, ``=``, is supported in template strings and behaves similar
 to how it behaves in f-strings, though due to limitations of the implementation
 there is a slight difference.
 
-In particular, ``t'{expr=}'`` is treated as ``t'expr={expr!r}'``:
+In particular, ``t'{expression=}'`` is treated as ``t'expression={expression!r}'``:
 
 .. code-block:: python
 
     name = "World"
     template = t"Hello {name=}"
     assert template.strings[0] == "Hello name="
     assert template.interpolations[0].value == "World"
-    assert template.interpolations[0].conv == "r"
+    assert template.interpolations[0].conversion == "r"
 
-If a separate format string is also provided, ``t'{expr=:fmt}`` is treated instead as
-``t'expr={expr!s:fmt}'``.
+If a separate format string is also provided, ``t'{expression=:fmt}`` is treated 
+instead as ``t'expression={expression!s:fmt}'``.
 
-Whitespace is preserved in the debug specifier, so ``t'{expr = }'`` is treated as
-``t'expr = {expr!r}'``.
+Whitespace is preserved in the debug specifier, so ``t'{expression = }'`` is 
+treated as ``t'expression = {expression!r}'``.
 
 
 Raw Template Strings
@@ -509,12 +510,12 @@ specifiers like ``:.2f``. The full code is fairly simple:
 
     from string.templatelib import Template, Interpolation
 
-    def convert(value: object, conv: Literal["a", "r", "s"] | None) -> object:
-        if conv == "a":
+    def convert(value: object, conversion: Literal["a", "r", "s"] | None) -> object:
+        if conversion == "a":
             return ascii(value)
-        elif conv == "r":
+        elif conversion == "r":
             return repr(value)
-        elif conv == "s":
+        elif conversion == "s":
             return str(value)
         return value
 
@@ -524,8 +525,8 @@ specifiers like ``:.2f``. The full code is fairly simple:
             match item:
                 case str() as s:
                     parts.append(s)
-                case Interpolation(value, _, conv, format_spec):
-                    value = convert(value, conv)
+                case Interpolation(value, _, conversion, format_spec):
+                    value = convert(value, conversion)
                     value = format(value, format_spec)
                     parts.append(value)
         return "".join(parts)
@@ -595,7 +596,7 @@ We can implement an improved version of ``StructuredMessage`` using template str
         @property
         def values(self) -> Mapping[str, object]:
             return {
-                item.expr: item.value
+                item.expression: item.value
                 for item in self.template
                 if isinstance(item, Interpolation)
             }
@@ -615,7 +616,8 @@ class. With template strings it is no longer necessary for developers to make
 sure that their format string and values dictionary are kept in sync; a single
 template string literal is all that is needed. The ``TemplateMessage``
 implementation can automatically extract structured keys and values from
-the ``Interpolation.expr`` and ``Interpolation.value`` attributes, respectively.
+the ``Interpolation.expression`` and ``Interpolation.value`` attributes, 
+respectively.
 
 
 Approach 2: Custom Formatters
@@ -656,7 +658,7 @@ and a ``ValuesFormatter`` for JSON output:
     class ValuesFormatter(Formatter):
         def values(self, template: Template) -> Mapping[str, Any]:
             return {
-                item.expr: item.value
+                item.expression: item.value
                 for item in template
                 if isinstance(item, Interpolation)
             }
@@ -1193,10 +1195,10 @@ Earlier versions of this PEP proposed that the ``Template`` and ``Interpolation`
 types should have their own implementations of ``__eq__`` and ``__hash__``.
 
 ``Templates`` were considered equal if their ``strings`` and ``interpolations``
-were equal; ``Interpolations`` were considered equal if their ``value``, ``expr``,
-``conv``, and ``format_spec`` were equal. Interpolation hashing was similar to
-tuple hashing: an ``Interpolation`` was hashable if and only if its ``value``
-was hashable.
+were equal; ``Interpolations`` were considered equal if their ``value``, 
+``expression``, ``conversion``, and ``format_spec`` were equal. Interpolation 
+hashing was similar to tuple hashing: an ``Interpolation`` was hashable if and 
+only if its ``value`` was hashable.
 
 This was rejected because ``Template.__hash__`` so defined was not useful as a
 cache key in template processing code; we were concerned that it would be
@@ -1244,9 +1246,10 @@ There are several limitations with respect to round-tripping to the original
 source text:
 
 - ``Interpolation.format_spec`` defaults to ``""`` if not provided. It is therefore
-  impossible to distinguish ``t"{expr}"`` from ``t"{expr:}"``.
+  impossible to distinguish ``t"{expression}"`` from ``t"{expression:}"``.
 - The debug specifier, ``=``, is treated as a special case. It is therefore not
-  possible to distinguish ``t"{expr=}"`` from ``t"expr={expr}"``.
+  possible to distinguish ``t"{expression=}"`` from 
+  ``t"expression={expression}"``.
 - Finally, format specifiers in f-strings allow arbitrary nesting. In this PEP
   and in the reference implementation, the specifier is eagerly evaluated
   to set the ``format_spec`` in the ``Interpolation``, thereby losing
@@ -1302,23 +1305,24 @@ PEP adheres closely to :pep:`701`. Any changes to allowed values should be in a
 separate PEP.
 
 
-Removing ``conv`` From ``Interpolation``
-----------------------------------------
+Removing ``conversion`` From ``Interpolation``
+----------------------------------------------
 
-During the authoring of this PEP, we considered removing the ``conv`` attribute
-from ``Interpolation`` and specifying that the conversion should be performed
-eagerly, before ``Interpolation.value`` is set.
+During the authoring of this PEP, we considered removing the ``conversion`` 
+attribute from ``Interpolation`` and specifying that the conversion should be 
+performed eagerly, before ``Interpolation.value`` is set.
 
 This was done to simplify the work of writing template processing code. The
-``conv`` attribute is of limited extensibility (it is typed as
+``conversion`` attribute is of limited extensibility (it is typed as
 ``Literal["r", "s", "a"] | None``). It is not clear that it adds significant
 value or flexibility to template strings that couldn't better be achieved with
 custom format specifiers. Unlike with format specifiers, there is no
-equivalent to Python's :func:`python:format` built-in. (Instead, we include an
+equivalent to Python's :func:`python:format` built-in. (Instead, we include a
 sample implementation of ``convert()`` in the `Examples`_ section.)
 
-Ultimately we decided to keep the ``conv`` attribute in the ``Interpolation`` type
-to maintain compatibility with f-strings and to allow for future extensibility.
+Ultimately we decided to keep the ``conversion`` attribute in the 
+``Interpolation`` type to maintain compatibility with f-strings and to allow 
+for future extensibility.
 
 
 Alternate Interpolation Symbols