Apply suggestions from code review

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

Author: TobiasWrigstad

peps/pep-0795.rst

@@ -75,8 +75,6 @@ DPO`_ and elsewhere. Based on feedback from DPO this rewrite:
    the inclusion of direct sharing across sub-interpreters motivate many
    of the design decisions
 
-We are very grateful to the many comments and threads on DPO that have
-contributed to this PEP.
 
 
 Motivation
@@ -161,9 +159,9 @@ only synchronising with its own GIL, they are not synchronising
 *with each other*. Sharing an *immutable* object avoids the need
 for synchronisation (except for reference counts, which we will
 return to later) -- however, if an immutable object has a mutable
-sub object, then sharing the immutable object indirectly also
-shares the mutable sub objets, which leads to the problems above.
-As we cannot prevent the sub object from being accessed, this
+sub-object, then sharing the immutable object indirectly also
+shares the mutable sub-objects, which leads to the problems above.
+As we cannot prevent the sub-object from being accessed, this
 motivates *deep* immutability.
 
 The picture below shows the situation above pictorially – the boxes
@@ -620,7 +618,7 @@ pre-freeze hook of the function type object:
 2. We freeze the globals copy which freezes the *values* which
    are shared between the globals dictionaries, but keeps the
    variables in the defining context's globals dictionary mutable.
-   Thus, ``x = [5, 6, 7]`` is permissable, and because that updates
+   Thus, ``x = [5, 6, 7]`` is permissible, and because that updates
    the sender's ``x`` to point to a mutable object, the subsequent
    append is permitted.
 
@@ -1385,7 +1383,7 @@ A type can become immutable if it satisfies *all* of the constraints below:
 Note the absence of a requirement that all functions defined in the
 class must be able to become immutable. **If a function fails to freeze, it will not be
 possible to call that function on the immutable type.** This alternative is
-preferrable to failing to freeze a type if not all its functions can become
+preferable to failing to freeze a type if not all its functions can become
 immutable and can be used to mimic statically checkable systems where it is
 not possible to call e.g. "non-const methods on const receivers", which will
 be checked dynamically and give a clearer error message than simply a failure
@@ -1878,7 +1876,7 @@ Changes to the C ABI
    This macro is used to check whether the argument (which must be
    castable to ``Py_Object *``) has its immutable bit set. If the
    argument is immutable, this evaluates to ``false``. If the argument
-   is writeable, it evalutes to ``true``.
+   is writeable, it evaluates to ``true``.
 ``Py_IsImmutable(obj)``
    This macro is used to check whether the argument has its immutable
    bit set.
@@ -1976,17 +1974,17 @@ full CPython test suite with the time it takes to run it with our
 changes on-top of it. Because of some intermittent tests failing
 on the CPython baseline, these tests were performed with our
 changes rebased on-top of CPython 3.14 (sha ``754e7c9b``). The
-test suite contained 1109 Python files containing a total of
-627917 LOC. While performance of test code is not
+test suite contained 1,109 Python files containing a total of
+627,917 LOC. While performance of test code is not
 necessarily indicative of performance of production code, the
 breadth and volume of the code gives a good indication of how
-successfull we are in meeting our goal. On average over 10 runs on
+successful we are in meeting our goal. On average over 10 runs on
 a single core to reduce jitter we found that our patch runs the
 tests 1.7% slower on average, which we consider a strong result
 given that we have added a write-barrier and not yet optimised any
-of our code. The Baseline finished in 334.6s +-0.89s; our
+of our code. The baseline finished in 334.6s +-0.89s; our
 build in 340.6s +-1.09s. Our build ran all the passing
-tests of the baseline, supressing one error due to missing
+tests of the baseline, suppressing one error due to missing
 documentation.
 
 
@@ -1999,7 +1997,7 @@ compared the time required to successfully freeze data structures
 (lists, trees, dictionaries) against the time require to pickle
 and unpickle the same data structures.
 
-Our benchmark generates 1000000 strings with eight characters and
+Our benchmark generates 1,000,000 strings with eight characters and
 inserts them into the respective data structures. We have two
 tests for dictionaries, both using random strings as keys, with
 one mapping to integers (dict-int) and the other mapping to
@@ -2268,7 +2266,7 @@ sharing *mutable* objects. We refer to this proposal as “data-race free
 Python” or “DRF Python” for short. In that future proposal, mutable
 objects will only be accessible to one sub-interpreter at a time, but
 can be passed around and shared by reference. We believe that making
-Python data-race free is the right programming model for the langauge,
+Python data-race free is the right programming model for the language,
 and aim to be compatible with both sub-interpreters and free-threaded
 Python.
 
@@ -2297,8 +2295,8 @@ Reference implementation
 Our `reference implementation`_, which we have made publicly available on
 Github, implements all of the features described above.
 We steal a bit from the top of the reference count in the object header. In 64-bit
-python this comes from the (currently unused) top word and thus has no impact at
-all on the runtime. In 32-bit python, the second bit of the word is used (since negative
+Python this comes from the (currently unused) top word and thus has no impact at
+all on the runtime. In 32-bit Python, the second bit of the word is used (since negative
 reference counts are used as necessary error conditions. The core functionality
 for immutability is provided in an (internal) ``immutability.h`` header and
 additional ``immutability.c`` file, though the C ABI macros and error function are