Apply suggestions from code review.

Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>

Author: ericsnowcurrently

Doc/library/concurrent.interpreters.rst

@@ -1,8 +1,8 @@
-:mod:`!concurrent.interpreters` --- Multiple Interpreters in the Same Process
+:mod:`!concurrent.interpreters` --- Multiple interpreters in the same process
 =============================================================================
 
 .. module:: concurrent.interpreters
-   :synopsis: Multiple Interpreters in the Same Process
+   :synopsis: Multiple interpreters in the same process
 
 .. moduleauthor:: Eric Snow <ericsnowcurrently@gmail.com>
 .. sectionauthor:: Eric Snow <ericsnowcurrently@gmail.com>
@@ -38,7 +38,7 @@ interfaces on top of the lower level :mod:`!_interpreters` module.
 .. include:: ../includes/wasm-notavail.rst
 
 
-Key Details
+Key details
 -----------
 
 Before we dive into examples, there are a small number of details
@@ -162,7 +162,7 @@ Exceptions
 .. XXX Add functions for communicating between interpreters.
 
 
-Basic Usage
+Basic usage
 -----------
 
 Creating an interpreter and running code in it::

Doc/library/concurrent.rst

@@ -1,7 +1,7 @@
 The :mod:`!concurrent` package
 ==============================
 
-Currently, there are only two modules in this package:
+This package contains the following modules:
 
 * :mod:`concurrent.futures` -- Launching parallel tasks
 * :mod:`concurrent.interpreters` -- Multiple interpreters in the same process

Doc/whatsnew/3.14.rst

@@ -132,10 +132,10 @@ PEP 734: Multiple Interpreters in the Stdlib
 The CPython runtime supports running multiple copies of Python in the
 same process simultaneously and has done so for over 20 years.
 Each of these separate copies is called an "interpreter".
-However, the feature has been available only through the C-API.
+However, the feature had been available only through the C-API.
 
 That limitation is removed in the 3.14 release,
-with the new :mod:`concurrent.interpreters` module!
+with the new :mod:`concurrent.interpreters` module.
 
 There are at least two notable reasons why using multiple interpreters
 is worth considering:
@@ -147,7 +147,7 @@ For some use cases, concurrency in software enables efficiency and
 can simplify software, at a high level.  At the same time, implementing
 and maintaining all but the simplest concurrency is often a struggle
 for the human brain.  That especially applies to plain threads
-(e.g. :mod:`threading`), where all memory is shared between all threads.
+(for example, :mod:`threading`), where all memory is shared between all threads.
 
 With multiple isolated interpreters, you can take advantage of a class
 of concurrency models, like CSP or the actor model, that have found
@@ -204,11 +204,11 @@ stopped sharing the :term:`GIL`.  Likewise, we expect to slowly see
 libraries on PyPI for high-level abstractions on top of interpreters.
 
 Regarding extension modules, work is in progress to update some PyPI
-projects, as well as tools like Cython, PyBind11, Nanobind, and PyO3.
+projects, as well as tools like Cython, pybind11, nanobind, and PyO3.
 The steps for isolating an extension module are found at
 :ref:`isolating-extensions-howto`.  Isolating a module has a lot of
 overlap with what is required to support
-:ref:`free-threadeding <whatsnew314-free-threaded-cpython>`,
+:ref:`free-threading <whatsnew314-free-threaded-cpython>`,
 so the ongoing work in the community in that area will help accelerate
 support for multiple interpreters.