Minor changes to PEP453 for grammar and content

pep-0453.txt

@@ -17,8 +17,8 @@ Abstract
 
 This PEP proposes that the `pip`_ package manager be made available by
 default when installing CPython and when creating virtual environments
-using the standard library's ``venv`` module (including via the
-``pyvenv`` command line utility).
+using the standard library's ``venv`` module via the ``pyvenv`` command line
+utility).
 
 To clearly demarcate development responsibilities, and to avoid
 inadvertently downgrading ``pip`` when updating CPython, the proposed
@@ -64,12 +64,12 @@ it, and how to install it. The effect of this is that third-party Python
 projects are currently required to choose from a variety of undesirable
 alternatives:
 
-* assume the user already has a suitable cross-platform package manager
-  installed
-* duplicate the instructions and tell their users how to install the
-  package manager
-* completely forgo the use of dependencies to ease installation concerns
-  for their users
+* Assume the user already has a suitable cross-platform package manager
+  installed.
+* Duplicate the instructions and tell their users how to install the
+  package manager.
+* Completely forgo the use of dependencies to ease installation concerns
+  for their users.
 
 All of these available options have significant drawbacks.
 
@@ -79,7 +79,7 @@ doesn't work. Some operating systems may ease this pain by providing a
 global hook that looks for commands that don't exist and suggest an OS
 package they can install to make the command work, but that only works
 on systems with platform package managers (such as major Linux
-distributions). No such assistance is availabe for Windows and
+distributions). No such assistance is available for Windows and
 Mac OS X users. The challenges of dealing with this problem are a
 regular feature of feedback the core Python developers receive from
 professional educators and others introducing new users to Python.
@@ -210,7 +210,7 @@ Implementation strategy
 To ensure there is no need for network access when installing Python or
 creating virtual environments, the ``extractpip`` module will, as an
 implementation detail, include a complete private copy of pip and its
-dependencies which will be used to extra pip and install it into the target
+dependencies which will be used to extract pip and install it into the target
 environment. It is important to stress that this private copy of pip is
 *only* an implementation detail and it should *not* be relied on or
 assumed to exist beyond the public capabilities exposed through the
@@ -225,7 +225,7 @@ to include private copies of ``pip`` and ``setuptools`` as wheel files
 contact PyPI (instead installing directly from the private wheel files.
 
 Rather than including separate code to handle the bootstrapping, the
-``extractpip`` module will manipulating sys.path appropriately to allow
+``extractpip`` module will manipulate sys.path appropriately to allow
 the wheel files to be used to install themselves, either into the current
 Python installation or into a virtual environment (as determined by the
 options passed to the bootstrap command).
@@ -267,11 +267,15 @@ The proposed ``extractpip`` module API consists of the following two
 functions::
 
     def version():
-        """Returns a string specifying the bootstrapped version of pip"""
+        """
+        Returns a string specifying the bundled version of pip.
+        """
 
     def bootstrap(root=None, upgrade=False, user=False, verbosity=0):
-        """Bootstrap pip into the current Python installation (or the given
-           root directory)"""
+        """
+        Bootstrap pip into the current Python installation (or the given root
+        directory).
+        """
 
 
 Invocation from the CPython installers
@@ -390,7 +394,7 @@ This PEP proposes that, if pip still requires it as a dependency,
 to the private copy of ``extractpip``). ``python -m extractpip`` will then
 install the private copy in addition to installing ``pip`` itself.
 
-However, this behaviour is officially considered an implementation
+However, this behavior is officially considered an implementation
 detail. Other projects which explicitly require ``setuptools`` must still
 provide an appropriate dependency declaration, rather than assuming
 ``setuptools`` will always be installed alongside ``pip``.
@@ -500,10 +504,10 @@ above.
 
 Adding the scripts directory to the system PATH would mean that ``pip``
 works reliably in the "only one Python installation on the system PATH"
-case, with ``py -m pip`` needed only to select a non-default version in
-the parallel installation case (and outside a virtual environment). This
-change should also make the ``pyvenv`` command substantially easier to
-invoke on Windows, along with all scripts installed by ``pip``,
+case, with ``py -m pip``, ``pipX``, or ``pipX.Y`` needed only to select a
+non-default version in the parallel installation case (and outside a virtual
+environment). This change should also make the ``pyvenv`` command substantially
+easier to invoke on Windows, along with all scripts installed by ``pip``,
 ``easy_install`` and similar tools.
 
 While the script invocations on recent versions of Python will run through
@@ -531,8 +535,8 @@ downstream distributors:
 
 * Do not remove the bundled copy of pip.
 
-  * This is required for offline installation of pip into a virtual
-    environment by the ``venv`` module.
+  * This is required for installation of pip into a virtual environment by the
+    ``venv`` module.
   * This is similar to the existing ``virtualenv`` package for which many
     downstream distributors have already made exception to the common
     "debundling" policy.
@@ -629,7 +633,7 @@ explicitly invoking ``pip`` following installation).
 
 As a result, the PEP was simplified to the current design, where the
 bootstrapping *always* uses the private copy of ``pip``. Contacting PyPI
-is now always an explicit seperate step, with direct access to the full
+is now always an explicit separate step, with direct access to the full
 pip interface.
 
 
@@ -656,8 +660,8 @@ Including pip directly in the standard library
 Similar to this PEP is the proposal of just including pip in the standard
 library. This would ensure that Python always includes pip and fixes all of the
 end user facing problems with not having pip present by default. This has been
-rejected because we've learned through the inclusion and history of
-``distutils`` in the standard library that losing the ability to update the
+rejected because we've learned, through the inclusion and history of
+``distutils`` in the standard library, that losing the ability to update the
 packaging tools independently can leave the tooling in a state of constant
 limbo. Making it unable to ever reasonably evolve in a time frame that actually
 affects users as any new features will not be available to the general
@@ -693,8 +697,8 @@ Defaulting to --user installation
 ---------------------------------
 
 Some consideration was given to bootstrapping pip into the per-user
-site-packages directory by default. However, this behaviour would be
-surprising (as it differs from the default behaviour of pip itself)
+site-packages directory by default. However, this behavior would be
+surprising (as it differs from the default behavior of pip itself)
 and is also not currently considered reliable (there are some edge cases
 which are not handled correctly when pip is installed into the user
 site-packages directory rather than the system site-packages).