Tweak wording based on feedback

Author: njsmith

pep-513.rst

@@ -215,17 +215,17 @@ libpythonX.Y.so.1
 -----------------
 
 Note that ``libpythonX.Y.so.1`` is *not* on the list of libraries that
-a ``manylinux1`` extension is allowed to link to. It turns out that
-this is unnecessary in almost all cases: the way ELF linking works,
-extension modules that are loaded into the interpreter automatically
-get access to all of the interpreter's symbols, regardless of whether
-or not the extension itself is explicitly linked against
-libpython. Furthermore, explicit linking to libpython creates problems
-in the common configuration where Python is not built with
-``--enable-shared``. In particular, on Debian and Ubuntu systems,
-``apt install pythonX.Y`` does not even install ``libpythonX.Y.so.1``,
-meaning that any wheel that *did* depend on ``libpythonX.Y.so.1``
-could fail to import.
+a ``manylinux1`` extension is allowed to link to. Explicitly linking
+to ``libpythonX.Y.so.1`` is unnecessary in almost all cases: the way
+ELF linking works, extension modules that are loaded into the
+interpreter automatically get access to all of the interpreter's
+symbols, regardless of whether or not the extension itself is
+explicitly linked against libpython. Furthermore, explicit linking to
+libpython creates problems in the common configuration where Python is
+not built with ``--enable-shared``. In particular, on Debian and
+Ubuntu systems, ``apt install pythonX.Y`` does not even install
+``libpythonX.Y.so.1``, meaning that any wheel that *did* depend on
+``libpythonX.Y.so.1`` could fail to import.
 
 There is one situation where extensions that are linked in this way
 can fail to work: if a host program (e.g., ``apache2``) uses