Grammar touch-ups

pep-0453.txt

@@ -17,7 +17,7 @@ Abstract
 This PEP proposes the inclusion of a method for explicitly bootstrapping
 `pip`_ as the default package manager for Python. It also proposes that the
 distributions of Python available via Python.org will automatically run this
-explicit bootstrapping method and a recommendation to third party
+explicit bootstrapping method and a recommendation to third-party
 redistributors of Python to also provide pip by default (in a way reasonable
 for their distributions).
 
@@ -39,7 +39,7 @@ the core interpreter and standard library.
 Rationale
 =========
 
-Installing a third party package into a freshly installed Python requires
+Installing a third-party package into a freshly installed Python requires
 first installing the package manager. This requires users ahead of time to
 know what the package manager is, where to get them from, and how to install
 them. The effect of this is that these external projects are required to
@@ -126,7 +126,7 @@ and then install it. This process is security sensitive, difficult to get
 right, and evolves along with the rest of packaging.
 
 Instead of attempting to maintain a "mini pip" for the sole purpose of
-installing pip the ``getpip`` module will, as an implementation detail,
+installing pip, the ``getpip`` module will, as an implementation detail,
 include a private copy of pip and its dependencies which will be used to
 discover and install pip from PyPI. It is important to stress that this
 private copy of pip is *only* an implementation detail and it should *not*
@@ -135,7 +135,7 @@ be relied on or assumed to exist.
 Not all users will have network access to PyPI whenever they run the
 bootstrap. In order to ensure that these users will still be able to
 bootstrap pip the bootstrap will fallback to simply installing the included
-copy of pip. The pip ``--no-download`` command line option will be supported
+copy of pip. The pip ``--no-download`` command-line option will be supported
 to force installation of the bundled version, without even attempting to
 contact PyPI.
 
@@ -194,7 +194,7 @@ Updating the bundled pip
 
 In order to keep up with evolutions in packaging as well as providing users
 who are using the offline installation method with as recent version as
-possible the ``getpip`` module should be updated to the latest versions of
+possible, the ``getpip`` module should be updated to the latest versions of
 everything it bootstraps. After each new pip release, and again during the
 preparation for any release of Python, a script, provided as part of this
 PEP, should be run to ensure the bundled packages have been updated to the
@@ -229,20 +229,20 @@ rely on) upgraded versions of ``pip`` even in maintenance releases.
 Pre-installation
 ================
 
-During the installation of Python from Python.org ``python -m getpip`` should
+During the installation of Python from Python.org, ``python -m getpip`` should
 be executed, leaving people using the Windows or OSX installers with a working
 copy of pip once the installation has completed. The exact method of this is
 left up to the maintainers of the installers, however if the bootstrapping is
 optional it should be opt-out rather than opt-in.
 
 The Windows and OSX installers distributed by Python.org will automatically
-attempt to run ``python -m getpip`` by default however the ``make install``
+attempt to run ``python -m getpip`` by default, however the ``make install``
 and ``make altinstall`` commands of the source distribution will not. Note
 that ``getpip`` itself will still be installed normally (as it is a regular
 part of the standard library), only the installation of pip and its
 dependencies will be skipped.
 
-Keeping the pip bootstrapping as a separate step for make based
+Keeping the pip bootstrapping as a separate step for ``make``-based
 installations should minimize the changes CPython redistributors need to
 make to their build processes. Avoiding the layer of indirection through
 ``make`` for the getpip invocation also ensures those installing from a custom
@@ -278,7 +278,7 @@ directory. This PEP proposes that this be changed to also add the scripts
 directory.
 
 Without this change, the most reliable way to invoke pip on Windows (without
-tinkering with paths) is actually be ``py -m pip`` (or ``py -3 -m pip``
+tinkering with paths) will actually be ``py -m pip`` (or ``py -3 -m pip``
 if both Python 2 and 3 are installed) rather than simply calling ``pip``.
 
 Adding the scripts directory to the system PATH would mean that ``pip``
@@ -300,8 +300,8 @@ To make the ``venv`` more useful to users it will be modified to issue the
 pip bootstrap by default inside of the new environment while creating it. This
 will allow people the same convenience inside of the virtual environment as
 this PEP provides outside of it as well as bringing the ``venv`` module closer
-to feature parity with the external ``virtualenv`` package making it a more
-suitable replacement. To handles cases where a user does not wish to have pip
+to feature parity with the external ``virtualenv`` package, making it a more
+suitable replacement. To handle cases where a user does not wish to have pip
 bootstrapped into their virtual environment a ``--without-pip`` option will be
 added. The ``--no-download`` option will also be supported, to force the
 use of the bundled ``pip`` rather than retrieving the latest version from
@@ -325,8 +325,8 @@ Recommendations for Downstream Distributors
 
 A common source of Python installations are through downstream distributors
 such as the various Linux Distributions [#ubuntu]_ [#debian]_ [#fedora]_, OSX
-package managers [#homebrew]_, or python specific tools [#conda]_. In order to
-provide a consistent, user friendly experience to all users of Python
+package managers [#homebrew]_, or python-specific tools [#conda]_. In order to
+provide a consistent, user-friendly experience to all users of Python
 regardless of how they attained Python this PEP recommends and asks that
 downstream distributors: