Apply suggestions from code review

Co-authored-by: Carol Willing <[email protected]>
Co-authored-by: Pradyun Gedam <[email protected]>

Author: 3 people

peps/pep-0771.rst

@@ -94,7 +94,7 @@ 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
+broken installation, and this is a commonly reported support issue for some of these
 packages.
 
 Rationale
@@ -214,7 +214,7 @@ 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), so
+``package`` appears elsewhere in the dependency tree 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
@@ -236,9 +236,9 @@ Finally, we note (as also discussed in `Relying on tooling to deselect
 any default extras`_) that package installers are allowed to implement their
 own options to control the above behavior, for example implementing an option
 that disables default extras for some or all packages regardless of where these
-packages appear in the dependency tree -- although if such options are
-implemented, they should be opt-in, and users should experience the above
-behavior as default.
+packages appear in the dependency tree. If such tool-specific options are
+implemented, tool developers should make these opt-in,
+and users should experience the above PEP 771 behavior as default.
 
 Examples
 --------
@@ -673,13 +673,9 @@ 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
 adds a default extra, then unless all downstream packages update their
 dependencies to specifically request a minimal installation, the defaults will
-often end up getting installed. A concrete example of this is that the `pytest
-<https://docs.pytest.org>`_ package has almost 1500 plugins at the time of
-writing, all of which depend on pytest. If pytest was to start using a default
-extra, it would need to consider this very carefully, as if the plugins are not
-updated, installing any plugin will result in the default extra being
-installed. This is not to say that it should not use default extras, but just
-that the decision should be considered and planned carefully.
+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.
 
 Inheriting from default extras
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -752,7 +748,7 @@ Documenting packages with default extras
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Regardless of how default extras are used, package authors should aim to ensure
-that the documentation for their package makes it clear how extras are to be
+that their package's documentation makes it clear how extras are to be
 used. 'Best practices' documentation should mention:
 
 * that installing ``package`` will be equivalent to ``package[<default extras>]``