Fix lint/whitespace issue.

Author: davepeck

peps/pep-0750.rst

@@ -134,7 +134,7 @@ see the `Raw Template Strings`_ section below for more information.
 The ``Template`` Type
 ---------------------
 
-Template strings evaluate to an instance of a new immutable type, 
+Template strings evaluate to an instance of a new immutable type,
 ``string.templatelib.Template``:
 
 .. code-block:: python
@@ -233,10 +233,10 @@ The ``expression`` attribute is the *original text* of the interpolation:
     template = t"Hello {name}"
     assert template.interpolations[0].expression == "name"
 
-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 
+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 ``conversion`` attribute is the :ref:`optional conversion <python:formatstrings>`
@@ -287,7 +287,7 @@ did not round the value to two decimal places when processed.
 The ``Template.values`` Property
 --------------------------------
 
-The ``Template.values`` property is a shortcut for accessing the ``value`` 
+The ``Template.values`` property is a shortcut for accessing the ``value``
 attribute of each ``Interpolation`` in the template and is equivalent to:
 
 .. code-block:: python
@@ -351,8 +351,8 @@ in the output of the ``__iter__()`` method:
     # However, the strings attribute contains empty strings:
     assert template.strings == ("", "", "")
 
-Template processing code can choose to work with any combination of  
-``strings``, ``interpolations``, ``values``, and ``__iter__()`` based on 
+Template processing code can choose to work with any combination of
+``strings``, ``interpolations``, ``values``, and ``__iter__()`` based on
 requirements and convenience.
 
 
@@ -464,10 +464,10 @@ In particular, ``t'{expression=}'`` is treated as ``t'expression={expression!r}'
     assert template.interpolations[0].value == "World"
     assert template.interpolations[0].conversion == "r"
 
-If a separate format string is also provided, ``t'{expression=:fmt}`` is treated 
+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'{expression = }'`` is 
+Whitespace is preserved in the debug specifier, so ``t'{expression = }'`` is
 treated as ``t'expression = {expression!r}'``.
 
 
@@ -664,7 +664,7 @@ 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.expression`` and ``Interpolation.value`` attributes, 
+the ``Interpolation.expression`` and ``Interpolation.value`` attributes,
 respectively.
 
 
@@ -1243,9 +1243,9 @@ 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``, 
-``expression``, ``conversion``, and ``format_spec`` were equal. Interpolation 
-hashing was similar to tuple hashing: an ``Interpolation`` was hashable if and 
+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
@@ -1288,8 +1288,8 @@ Enable Full Reconstruction of Original Template Literal
 
 Earlier versions of this PEP attempted to make it possible to fully reconstruct
 the text of the original template string from a ``Template`` instance. This was
-rejected as being overly complex. The mapping between template literal source 
-and the underlying AST is not one-to-one and there are several limitations with 
+rejected as being overly complex. The mapping between template literal source
+and the underlying AST is not one-to-one and there are several limitations with
 respect to round-tripping to the original source text.
 
 First, ``Interpolation.format_spec`` defaults to ``""`` if not provided:
@@ -1303,7 +1303,7 @@ First, ``Interpolation.format_spec`` defaults to ``""`` if not provided:
     assert template2.interpolations[0].format_spec == ""
 
 Next, the debug specifier, ``=``, is treated as a special case and is processed
-before the AST is created. It is therefore not possible to distinguish 
+before the AST is created. It is therefore not possible to distinguish
 ``t"{expression=}"`` from ``t"expression={expression!r}"``:
 
 .. code-block:: python
@@ -1318,9 +1318,9 @@ before the AST is created. It is therefore not possible to distinguish
     assert template2.interpolations[0].expression == "value"
     assert template2.interpolations[0].conversion == "r"
 
-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 the original 
+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 the original
 expressions. For example:
 
 .. code-block:: python
@@ -1378,8 +1378,8 @@ separate PEP.
 Removing ``conversion`` From ``Interpolation``
 ----------------------------------------------
 
-During the authoring of this PEP, we considered removing the ``conversion`` 
-attribute from ``Interpolation`` and specifying that the conversion should be 
+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
@@ -1390,8 +1390,8 @@ custom format specifiers. Unlike with format specifiers, there is no
 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 ``conversion`` attribute in the 
-``Interpolation`` type to maintain compatibility with f-strings and to allow 
+Ultimately we decided to keep the ``conversion`` attribute in the
+``Interpolation`` type to maintain compatibility with f-strings and to allow
 for future extensibility.