fix some grammar typos and build

Author: Gobot1234

peps/pep-0718.rst

@@ -201,28 +201,9 @@ The following code snippet would fail at runtime without this change as
 Interactions with ``@typing.overload``
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Overloaded functions should work much the same as already, since they have no effect on
-the runtime type. This change will lead to more expressiveness with user's able to
-decide and the behaviour/overload can be specified by the developer rather than leaving
-it to ordering of overloads/unions.
-
-.. code-block:: python
-
-   # N.B. `class bytes(Sequence[int]): ...` and `Foo` is a non-specified generic type
-   @overload
-   def seq_first[T: Sequence[int]](x: T) -> T: ...
-   @overload
-   def seq_first[T: bytes](x: T) -> Foo[T]: ...
-
-   @overload
-   def bytes_first[T: bytes](x: T) -> Foo[T]: ...
-   @overload
-   def bytes_first[T: Sequence[int]](x: T) -> T: ...
-
-   reveal_type(seq_first(b""))  # type is bytes
-   reveal_type(bytes_first(b""))  # type is Foo[bytes]
-
-Explicit specialisation will restrict the set of available overloads
+Overloaded functions should work much the same as they already do, since they do not
+affect the runtime type. Explicit specialisation will restrict the set of available
+overloads.
 
 .. code-block:: python
 
@@ -232,33 +213,32 @@ Explicit specialisation will restrict the set of available overloads
    def make(x: str, y: str) -> tuple[int, int]: ...
 
    reveal_type(make[int](1))             # type is int
-   reveal_type(make[int]("foo", "bar"))  # Invalid: no overload for `make[int](x:str, y: str)` found, a similar overload exists but explicit specialisation prevented its use
+   reveal_type(make[int]("foo", "bar"))  # Invalid: no overload for `make[int](x: str, y: str)` found, a similar overload exists but explicit specialisation prevented its use
 
 Functions Parameterized by ``TypeVarTuple``\ s
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Currently type checkers disallow the use of multiple ``TypeVarTuple`` \s in it's
-generic parameters, however it is currently valid to have a function as such
+Currently, type checkers disallow the use of multiple ``TypeVarTuple``\s in their
+generic parameters; however, it is currently valid to have a function as such:
 
 .. code-block:: python
 
    def foo[*T, *U](bar: Bar[*T], baz: Baz[*U]): ...
    def spam[*T](bar: Bar[*T]): ...
 
-This PEP does not allow similar functions to be subscripted, for the same reason as
-defined in :pep:`PEP 646<646#multiple-type-variable-tuples-not-allowed>`.
+This PEP does not allow functions like ``foo`` to be subscripted, for the same reason
+as defined in :pep:`PEP 646<646#multiple-type-variable-tuples-not-allowed>`.
 
 .. code-block:: python
 
    foo[int, str, bool, complex](Bar(), Baz())  # Invalid: cannot determine which parameters are passed to *T and *U. Explicitly parameterise the instances individually
    spam[int, str, bool, complex](Bar())        # OK
 
-
 Binding Rules
 ^^^^^^^^^^^^^
-Subscriptions on methods (including classmethods, staticmethods etc.) should only have
-access to their function's type parameters and not the enclosing class's. Subscription
-should follow the rules specified in :pep:`PEP 696<696#binding-rules>` methods should
-be bound on attribute access.
+Method subscription (including ``classmethods``, ``staticmethods``, etc.) should only
+have access tos their function's type parameter and not the enclosing class's.
+Subscription should follow the rules specified in :pep:`PEP 696<696#binding-rules>`;
+methods should bind type parameters on attribute access.
 
 .. code-block:: python