Apply suggestions from code review

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

Author: iritkatriel

peps/pep-0765.rst

@@ -169,7 +169,7 @@ Change Semantics
 ----------------
 
 It `was suggested <https://discuss.python.org/t/pep-765-disallow-return-break-continue-that-exit-a-finally-block/71348/32>`__
-to change the semantics of control flow instruction in finally such that an
+to change the semantics of control flow instructions in finally such that an
 in-flight exception takes precedence over them.  In other words, a ``return``,
 ``break`` or ``continue`` would be permitted, and would exit the ``finally``
 block, but the exception would still be raised.
@@ -182,7 +182,7 @@ in rare edge cases at runtime, and is not guaranteed to be detected in testing.
 Even if the code is wrong, and has an exception swallowing bug, it could be
 hard for users to understand why a program started raising exceptions in 3.14,
 while it did not in 3.13.
-In contrast, a ``SyntaxError`` is likely to be seen during testing, it would
+In contrast, a ``SyntaxWarning`` is likely to be seen during testing, it would
 point to the precise location of the problem in the code, and it would not
 prevent the program from running.
 
@@ -191,7 +191,7 @@ allowing control flow statements is not that this would be useful, but rather
 the desire for orthogonality of features (which, as we mentioned in the
 introduction, is already violated in the case of ``except*`` clauses). However,
 the proposed semantics are complicated because they suggest that ``return``,
-``break`` and ``continue`` behave as they normally when finally is called
+``break`` and ``continue`` behave as they normally when ``finally`` is used
 without an in-flight exception, but turn into something like a bare ``raise``
 when there is one. It is hard to claim that the features are orthogonal if
 the presence of one changes the semantics of the other.