diff --git a/pep-0637.rst b/pep-0637.rst
index 4a161729b..3436e0dd0 100644
--- a/pep-0637.rst
+++ b/pep-0637.rst
@@ -159,7 +159,7 @@ specification would improve notation and provide additional value:
    exactly this notation in its "Unpacking: Star Operator" section.
 
 It is important to note that how the notation is interpreted is up to the
-implementation. This PEP only defines and dictates the behavior of python
+implementation. This PEP only defines and dictates the behavior of Python
 regarding passed keyword arguments, not how these arguments should be
 interpreted and used by the implementing class.
 
@@ -172,7 +172,7 @@ and how it is different from a function call.
 
 Subscripting ``obj[x]`` is, effectively, an alternate and specialised form of
 function call syntax with a number of differences and restrictions compared to
-``obj(x)``. The current python syntax focuses exclusively on position to express
+``obj(x)``. The current Python syntax focuses exclusively on position to express
 the index, and also contains syntactic sugar to refer to non-punctiform
 selection (slices). Some common examples::
 
@@ -197,7 +197,7 @@ violate this intrinsic meaning.
 
 The second difference of the indexing notation compared to a function
 is that indexing can be used for both getting and setting operations.
-In python, a function cannot be on the left hand side of an assignment. In
+In Python, a function cannot be on the left hand side of an assignment. In
 other words, both of these are valid::
 
     >>> x = a[1, 2]
@@ -526,7 +526,7 @@ With the introduction of the new notation, a few corner cases need to be analyse
        # Given type(obj).__setitem__(obj, index, value):
        obj[1, value=3] = 5
 
-   This poses no issue because the value is passed automatically, and the python interpreter will raise
+   This poses no issue because the value is passed automatically, and the Python interpreter will raise
    ``TypeError: got multiple values for keyword argument 'value'``
 
 
@@ -621,7 +621,7 @@ Resolution of the indexing operation is performed through a call to the followin
 - ``PyObject_SetItem(PyObject *o, PyObject *key, PyObject *value)`` for the set operation
 - ``PyObject_DelItem(PyObject *o, PyObject *key)`` for the del operation
 
-These functions are used extensively within the python executable, and are
+These functions are used extensively within the Python executable, and are
 also part of the public C API, as exported by ``Include/abstract.h``. It is clear that
 the signature of this function cannot be changed, and different C level functions
 need to be implemented to support the extended call. We propose
@@ -791,7 +791,7 @@ The problems with this approach were found to be:
 
 - the solution relies on the assumption that all keyword indices necessarily map
   into positional indices, or that they must have a name. This assumption may be
-  false: xarray, which is the primary python package for numpy arrays with
+  false: xarray, which is the primary Python package for numpy arrays with
   labelled dimensions, supports indexing by additional dimensions (so called
   "non-dimension coordinates") that don't correspond directly to the dimensions
   of the underlying numpy array, and those have no position to match up to.
@@ -911,7 +911,7 @@ non-default arguments after defaulted one::
     def __setitem__(self, index=SENTINEL, value=NEVERUSED, *, k)
 
 which seems ugly, redundant and confusing. We must therefore accept that some
-form of sentinel index must be passed by the python implementation when the
+form of sentinel index must be passed by the Python implementation when the
 ``obj[k=3]`` notation is used. This also means that default arguments to those
 parameters are simply never going to be used (but it's already the
 case with the current implementation, so no change there).
@@ -1040,7 +1040,7 @@ Common objections
    function calls are out of the question.  Moreover, function calls do not handle
    slice notation, which is commonly used in some cases for arrays.
 
-   One problem is type hint creation has been extended to built-ins in python 3.9,
+   One problem is type hint creation has been extended to built-ins in Python 3.9,
    so that you do not have to import Dict, List, et al anymore.
 
    Without kwdargs inside ``[]``, you would not be able to do this::