Grammar and spelling

Author: astrofrog

peps/pep-0771.rst

@@ -25,7 +25,7 @@ Motivation
 
 Various use cases for default extras and possible solutions in this PEP were discussed
 extensively on `this DPO thread <https://discuss.python.org/t/adding-a-default-extra-require-environment/4898>`__.
-These fall into two broad cases that that provide the
+These fall into two broad cases that provide the
 motivation for the present PEP.
 
 Recommended but not required dependencies
@@ -35,7 +35,7 @@ Package maintainers often use extras to declare optional dependencies that
 extend the functionality or performance of a package. In some cases, it can be
 difficult to determine which dependencies should be required and which should be
 categorized as extras. A balance must be struck between the needs of typical
-users (who may prefer most features to be available 'by default') and users who
+users, who may prefer most features to be available by default, and users who
 want minimal installations without large, optional dependencies. One solution
 with existing Python packaging infrastructure is for package maintainers to
 define an extra called, for example, ``recommended``, which
@@ -71,15 +71,15 @@ is. Concrete examples of such frontends or backends include:
   <https://www.postgresql.org/>`_, `SQLite <https://www.sqlite.org/>`_
 
 With current packaging standards, maintainers have to either
-require one of the backends or frontends, or require users
-to always specify extras, e.g. ``package[backend]`` and therefore risk users
+require one of the backends or frontends or require users
+to always specify extras, e.g., ``package[backend]``, and therefore risk users
 having an unusable installation if they only install ``package``. Having a
 way to specify one or more default backend or frontend and providing a way to
 override these defaults would provide a much better experience for users, and
 the approach described in this PEP will allow this.
 
 Note that this PEP does not aim to address the issue of disallowing conflicting
-or incompatible extras - for example if a package requires exactly one frontend
+or incompatible extras, for example if a package requires exactly one frontend
 or backend package. There is currently no mechanism in Python packaging
 infrastructure to disallow conflicting or incompatible extras to be installed,
 and this PEP does not change that.
@@ -94,13 +94,13 @@ recommend a default extra to install a backend or frontend include:
 * `glueviz <https://www.glueviz.org>`_: ``glueviz[qt]``
 
 In all three cases, installing the package without any extras results in a
-broken installation (and this is a commonly reported issue for some of these
-packages).
+broken installation, and this is a commonly reported issue for some of these
+packages.
 
 Rationale
 =========
 
-A number of possible solutions have been extensively and vigorously discussed by
+A number of possible solutions have been extensively discussed 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
@@ -110,7 +110,7 @@ presented below:
 * is flexible enough to accommodate both of the major use cases described in `Motivation`_
 * re-uses the syntax from :pep:`508`
 
-It is the only solution out of all those discussed that meets all three criteria.
+It is the only solution, out of all those discussed, that meets all three criteria.
 
 Specification
 =============
@@ -121,7 +121,7 @@ Specification
 A new multiple-use metadata field, ``Default-Extra``, will be added to the `core package
 metadata <https://packaging.python.org/en/latest/specifications/core-metadata/#core-metadata>`_.
 For this field, each entry must be a string specifying an extra that will be
-automatically included when the package is installed without any extras specified explicitly.
+automatically included when the package is installed without any extras being specified explicitly.
 
 Only entries already specified in a `Provides-Extra
 <https://packaging.python.org/en/latest/specifications/core-metadata/#provides-extra-multiple-use>`_
@@ -174,7 +174,6 @@ and:
         "backend3"
     ]
 
-
 Overriding default extras
 -------------------------
 
@@ -309,7 +308,6 @@ could then use:
 
     $ pip install astropy[]
 
-
 Packages requiring at least one backend or frontend
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -483,8 +481,8 @@ Ideally, one may want the following behavior:
     $ pip install package[frontend2]  # installs frontend2 and default backend
     $ pip install package[backend1, frontend2]  # installs backend1 and frontend2
 
-However, this PEP chooses not to provide a mechanism for having the fact that
-``backend1`` is specified disabling the default backend but keep the default
+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.
 
 Maintainers should instead for now document that if a backend or frontend is
@@ -509,8 +507,8 @@ the default backend and frontend. They can then recommend that users do:
 This would allow (if desired) users to then get whatever the recommended backend
 is, even if that default changes in time.
 
-If there was a desire to implement a better solution in future, we believe this
-PEP does not preclude this. For example, one could imagine in future adding the
+If there is a desire to implement a better solution in future, we believe this
+PEP should not preclude this. For example, one could imagine in future adding the
 ability for an extra to specify *which* default extras it disables rather than
 disabling all default extras, but the default could still be for explicitly
 specified extras to disable all default extras, which would be consistent with
@@ -648,7 +646,7 @@ following recommendations would apply:
   the extra explicitly as long as possible (until it is clear that most/all users
   are using package installers that implement this PEP). There is no downside to
   keeping the extra be explicitly mentioned, but this will ensure that users with
-  modern tooling who do not read documentation (which may be a non-negligeable
+  modern tooling who do not read documentation (which may be a non-negligible
   fraction of the user community) will start getting the recommended
   dependencies by default.
 
@@ -816,8 +814,6 @@ In addition, `this branch <https://github.com/astrofrog/flit/tree/default-extras
 contains a modified version of the `Flit
 <https://flit.pypa.io/en/stable/>`_ package.
 
-
-
 The implementations above are proofs-of-concept at this time and the existing changes have
 not yet been reviewed by the relevant maintainers. Nevertheless, they are
 functional enough to allow for interested maintainers to try these out.
@@ -1051,7 +1047,6 @@ a ``setup.py`` file can do::
         extras_require={'': ['package_a']},
     )
 
-
 which is valid and equivalent to having ``package_a`` being defined in
 ``install_requires``, so changing the meaning of the empty string would
 break compatibility.