Apply suggestions from code review

Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>

Author: markshannon

peps/pep-0805.rst

@@ -27,7 +27,7 @@ PEP 703, Making the Global Interpreter Lock Optional in CPython, and PEP 554, Mu
 Multiple interpreters are both safe and support parallelism, but they are difficult to use and sharing objects
 between multiple interpreters without copying is impossible.
 PEP 703 supports parallel execution and sharing, but is unsafe as it allows race conditions.
-Race conditions allow dangerous and hard to find bugs. In the most extreme example, Therac-25 [1]_, a race condtion bug resulted in several fatalities. The trouble with race conditions is not that the bugs they introduce are necessarily worse than other bugs,
+Race conditions allow dangerous and hard to find bugs. In the most extreme example, Therac-25 [1]_, a race condition bug resulted in several fatalities. The trouble with race conditions is not that the bugs they introduce are necessarily worse than other bugs,
 but that they can be very hard to detect and may easily slip through testing.
 
 Parallelism, without strong support from the language and runtime, is extremely difficult to get right:
@@ -70,7 +70,7 @@ to one thread (the top-left quadrant), or that it is protected by a mutual exclu
 The PEP also proposes changes to CPython to prevent unsafe execution when mutable objects are shared.
 Finally, the PEP provides a generalization of the GIL to allow incrementally moving away from the GIL.
 
-This PEP is inspired by ideas from Ocaml, specifically Data Freedom à la Mode [2]_, and the Pyrona project [3]_.
+This PEP is inspired by ideas from OCaml, specifically Data Freedom à la Mode [2]_, and the Pyrona project [3]_.
 Many of the necessary technologies, such as biased and deferred reference counting, have been developed for PEP 703.
 
 Specification
@@ -100,7 +100,7 @@ Views, iterators and other objects that depend on the internal state of other mu
 those objects. For example, a ``listiterator`` of a *local* ``list`` will be *local*, but a ``listiterator`` of a *protected*
 ``list`` will be *protected*. Views and iterators of *immutable* (including STW mutable) objects will be *local* when created.
 
-All objects that not inherently immutable (like tuples or strings) will be created as *local*.
+All objects that are not inherently immutable (like tuples or strings) will be created as *local*.
 These *local* objects can later be made *immutable* or *protected*.
 
 Dictionaries and lists will support the ability to be made stop-the-world mutable on a per-object basis.
@@ -156,7 +156,7 @@ The ``__freeze__()`` will be added to all pure Python class as well as most stan
 ``list``, ``set`` and ``dict`` classes will gain a ``__freeze__()`` method.
 For immutable objects like ``tuple``, ``__freeze__()`` will be supported, but will have no effect.
 
-Note that freezing an object is a shallow operation; ``x.__freeze__()` only freezes ``x`` and not any of the objects
+Note that freezing an object is a shallow operation; ``x.__freeze__()`` only freezes ``x`` and not any of the objects
 that ``x`` refers to.
 
 The ``__freeze__`` method can be used to create classes of immutable objects, by calling ``__freeze__`` at the