Apply suggestions by @warsawnv

Author: astrofrog

peps/pep-0771.rst

@@ -100,7 +100,7 @@ packages.
 Rationale
 =========
 
-A number of possible solutions have been extensively discussed by
+A number of possible solutions have been discussed extensively by
 the community for several years, including in `this DPO thread
 <https://discuss.python.org/t/adding-a-default-extra-require-environment/4898>`__
 as well as in numerous issues and pull requests. The solution that is
@@ -214,7 +214,8 @@ once with no extras specified.
 
 An empty set of extras, such as ``package[]`` should be interpreted as meaning
 that the package should be installed *without* any default extras (unless
-``package`` appears elsewhere in the dependency tree as mentioned above). This
+``package`` appears elsewhere in the dependency tree, in which case, the default
+extra *would* be installed as mentioned above). This
 would provide a universal way of obtaining a minimal installation of a package.
 
 We also note that some tools such as `pip`_ currently ignore unrecognized
@@ -300,7 +301,7 @@ meaning that installing:
 
     $ pip install astropy
 
-would then also install optional but important optional dependencies such as
+would then also install optional but recommended dependencies such as
 `scipy <https://www.scipy.org>`_. Advanced users who want a minimal install
 could then use:
 
@@ -483,14 +484,14 @@ Ideally, one may want the following behavior:
     $ pip install package[backend1, frontend2]  # installs backend1 and frontend2
 
 However, this PEP chooses not to provide a mechanism for making it so that e.g., if
-``backend1`` is specified, this disabling the default backend but keeps the default
-frontend, since this adds complexity.
+``backend1`` is specified, the default backend would be disabled, but the
+default frontend would be enabled, since this adds complexity.
 
 Maintainers should instead for now document that if a backend or frontend is
 explicitly specified, both backend and frontend need to be specified.
 Discoverability for users who want to do this should not be an issue however since users
 need to read the documentation in any case to find out what backends or frontends are
-available, so they can be shown at the same time how do properly use the extras for
+available, so they can be shown at the same time how to properly use the extras for
 backends and frontends.
 
 One option to increase user friendliness is that maintainers can create extras
@@ -671,10 +672,14 @@ mean that all extras need to be defaults, and there is still scope for users to
 explicitly opt in to non-default extras.
 
 In essence, default extras should be considered just as 'weighty' as a required
-dependency. In some cases, if a package is widely used by many others, if it
+dependency. In some cases, if a package is widely used by many others and
 adds a default extra, then unless all downstream packages update their
 dependencies to specifically request a minimal installation, the defaults will
-Default extras should generally be treated with the same "weight" as required dependencies. When a package is widely used, introducing a default extra will result in that extra's dependencies being transitively included -- unless all downstream packages are updated to explicitly opt out using minimal installation specifications.
+Default extras should generally be treated with the same "weight" as required
+dependencies. When a package is widely used, introducing a default extra will
+result in that extra's dependencies being transitively included -- unless all
+downstream packages are updated to explicitly opt out using minimal installation
+specifications.
 
 As an example, the `pytest <https://docs.pytest.org/>`_ package currently has nearly 1,500 plugins that depend on it. If pytest were to add a default extra and those plugins were not updated accordingly, installing a plugin would include the default extras' dependencies. This doesn’t preclude the use of default extras, but addition of default extras requires careful evaluation of its downstream effects.
 
@@ -741,7 +746,7 @@ solved by changing the dependency tree to instead be::
     └── package2
         └── package1[]
 
-assuming that ``package2`` indeed does not depend on any features provided by
+assuming that indeed ``package2`` does not depend on any features provided by
 the extra dependencies of ``package1``. Authors therefore need to carefully
 consider a migration plan, coordinating with the authors of ``package2``.