PEP 585: Fix other occurrences of 'parametriz'

pep-0585.rst

@@ -52,14 +52,14 @@ recognize standard collections as generics.
 On the source level, 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
-parametrize standard collections, including builtins.  To reiterate,
+parameterize standard collections, including builtins.  To reiterate,
 that depends on the external tools understanding that this is valid.
 
 Implementation
 ==============
 
 Starting with Python 3.7, when ``from __future__ import annotations`` is
-used, function and variable annotations can parametrize standard
+used, function and variable annotations can parameterize standard
 collections directly.  Example::
 
     from __future__ import annotations
@@ -74,7 +74,7 @@ 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 become generic using
-``__class_getitem__()`` to parametrize contained types:
+``__class_getitem__()`` to parameterize contained types:
 
 * ``tuple``  # typing.Tuple
 * ``list``  # typing.List
@@ -295,7 +295,7 @@ In fact, forbidding instantiation of parameterized types is what the
 collections (instantiation of other parameterized types is allowed).
 
 The original reason for this decision was to discourage spurious
-parametrization which made object creation up to two orders of magnitude
+parameterization which made object creation up to two orders of magnitude
 slower compared to the special syntax available for those builtin
 collections.