Apply suggestions from Jelle's code review

Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
python · JelleZijlstra · Oct 10, 2024 · Oct 8, 2024 · Oct 8, 2024 · Oct 9, 2024
commit af735aea7693b9a8554ad2789e9328148dff5fbb
@@ -18,7 +18,7 @@ Previous efforts to improve the wheel specification
 :pep:`were deferred <491#pep-deferral>` to focus on other packaging
 specifications. Meanwhile, the use of wheels has changed dramatically in the
 last decade. There have been many requests for new wheel features over the
-years, however a fundamental obstacle to evolving the wheel specification has
+years; however, a fundamental obstacle to evolving the wheel specification has
 been that there is no defined process for how to handle adding
 backwards-incompatible features to wheels. Therefore, to enable other PEPs to
 describe new enhancements to the wheel specification, this PEP prescribes
@@ -136,7 +136,7 @@ not implement ``Wheel-Version`` checks. By using a different file extension,
 experiment with the new features right away. Users on older installers will
 simply ignore these new files.
 
-One rejected alternative would be to keep the .whl extension, but delay the
+One rejected alternative would be to keep the ``.whl`` extension, but delay the
 publishing of wheel 2.0 to PyPI. For more on that, please see Rejected Ideas.
 
 Recommended Build Backend Behavior with New Wheel Formats
@@ -237,11 +237,11 @@ wheel package format is necessary.
 
 Wheel Format Changes Should be Tied to CPython Releases
 -------------------------------------------------------
-The author of this PEP does not believe that tying wheel revisions to CPython
+I do not believe that tying wheel revisions to CPython
 releases is beneficial. The main benefit of doing so is to make adoption of new
 wheels predictable - users with the latest CPython get the latest package
-format! This choice has several issues however. First, by tying the new format
-to the latest CPython, it makes adoption much slower. Users on LTS versions of
+format! This choice has several issues however. First, tying the new format
+to the latest CPython makes adoption much slower. Users on LTS versions of
 Linux with older Python installations are free to update their pip in a virtual
 environment, but cannot update the version of Python as easily.  While some
 changes to the wheel format must be tied to CPython changes necessarily, such

@@ -61,7 +61,7 @@ in four years.
   :alt: A pie chart breaking down PyPI downloads by pip major version
 
 Over two thirds of users currently run ``pip`` from this year or last. However,
-about 7% are on a version that is four years or older(!). This indicates that
+about 7% are on a version that is at least four years old(!). This indicates that
 there is a long tail of users who do not regularly update their installers.
 
 Coming back to the initial question for PEP 777, it appears that caution should