[pep-585] Minor wording improvements

pep-0585.rst

@@ -20,7 +20,7 @@ a duplicated collection hierarchy in the ``typing`` module due to
 generics (for example ``typing.List`` and the built-in ``list``).
 
 This PEP proposes to enable support for the generics syntax in all
-standard collections available by the ``typing`` module.
+standard collections currently available in the ``typing`` module.
 
 
 Rationale and Goals
@@ -34,11 +34,11 @@ and easier for teachers to teach Python.
 Terminology
 ===========
 
-Generic (n.) - a type that can be parametrized, typically a container.
+Generic (n.) — a type that can be parametrized, typically a container.
 Also known as a *parametric type* or a *generic type*.  For example:
 ``dict``.
 
-Parametrized generic - a specific instance of a generic with the
+Parametrized generic — a specific instance of a generic with the
 expected types for container elements provided.  For example:
 ``dict[str, int]``.
 
@@ -49,7 +49,7 @@ Backwards compatibility
 The newly described functionality requires Python 3.9.  For use cases
 restricted to type annotations, Python files with the "annotations"
 future-import (available since Python 3.7) can use generics in
-combination with standard library collections.
+combination with standard collections, including builtins.
 
 Tooling, including type checkers and linters, will have to be adapted to
 recognize such generics usage as valid.
@@ -59,8 +59,8 @@ Implementation
 ==============
 
 Starting with Python 3.7, when ``from __future__ import annotations`` is
-used, function and variable annotations can specify generics directly on
-builtin types.  Example::
+used, function and variable annotations can parametrize standard
+collections directly.  Example::
 
     from __future__ import annotations
 
@@ -68,11 +68,11 @@ builtin types.  Example::
         ...
 
 Certain features of typing like type aliases or casting require putting
-types in runtime context, outside of annotations.  While these are
+types outside of annotations, in runtime context.  While these are
 relatively less common than type annotations, it's important to allow
-using the same type syntax in all contexts. This is why starting with
-Python 3.9, the following collections gain `__class_getitem__()` support
-for generics:
+using the same type syntax in all contexts.  This is why starting with
+Python 3.9, the following collections become generic using
+``__class_getitem__()`` to parametrize contained types:
 
 * ``tuple``  # typing.Tuple
 * ``list``  # typing.List
@@ -257,16 +257,17 @@ Given that the proxy type which preserves ``__origin__`` and
 introspection purposes, we might have disallowed instantiation of
 parametrized types.
 
-In fact, this is what the ``typing`` module does today for the parallels
-of builtin collections only.  Instantiation of other parametrized types
-is allowed.
+In fact, this is what the ``typing`` module does today for types which
+parallel builtin collections (instantiation of other parametrized types
+is allowed).
 
 The original reason for this decision was to discourage spurious
 parametrization which made object creation up to two orders of magnitude
-slower compared to the special syntax available for builtin types.
+slower compared to the special syntax available for those builtin
+collections.
 
 This rationale is not strong enough to allow the exceptional treatment
-of builtins.  All other parametrized types can still be instantiated,
+of builtins.  All other parametrized types can be instantiated,
 including parallels of collections in the standard library.  Moreover,
 Python allows for instantiation of lists using ``list()`` and some
 builtin collections don't provide special syntax for instantiation.