Fix typos

Author: cdce8p

peps/pep-0823.rst

@@ -67,7 +67,7 @@ An attribute or value is ``missing``
 Motivation
 ==========
 
-First officially proposed ten years ago in (the now deferred) :pep:`505`
+First officially proposed ten years ago in (the now deferred) :pep:`505`,
 the idea to add ``None``-aware access operators has been along for
 some time now, discussed at length in numerous threads, most recently
 in [#discuss_revisit_505]_ and [#discuss_safe_navigation_op]_. This PEP
@@ -760,11 +760,11 @@ If ``.b`` all of the sudden is also ``None``, it would still raise an
 issues. As the expression output can already be ``None``, the space of
 potential outputs didn't change and as such no error would appear.
 
-If it is the intend to catch all ``AttributeError`` and ``TypeError``,
+If it is the intent to catch all ``AttributeError`` and ``TypeError``,
 a try-except block can be used instead.
 
 As the ``?.`` and ``?[ ]`` would allow developers to be more explicit in
-their intend, this suggestion is rejected.
+their intent, this suggestion is rejected.
 
 Remove short-circuiting
 -----------------------
@@ -1237,21 +1237,21 @@ Proliferation of ``None`` in code bases
 ---------------------------------------
 
 One of the reasons why :pep:`505` stalled was that some expressed their
-concern how ``None``-aware access operators will effect the code written
+concern how ``None``-aware access operators will affect the code written
 by developers. If it is easier to work with ``optional`` attributes,
 this will encourage developers to use them more. They believe that e.g.
 returning an ``optional`` (can be ``None``) value from a function is
 usually an anti-pattern. In an ideal world the use of ``None`` would
 be limited as much as possible, for example with early data validation.
 
-It is certainly true that new language features effect how the language
+It is certainly true that new language features affect how the language
 as a whole develops. Therefore any changes should be considered carefully.
 However, just because ``None`` represents an anti-pattern for some, has
 not prevented the community as a whole from using it extensively. Rather
 the lack of ``None``-aware access operators has stopped developers from
 writing concise expressions to access ``optional`` attributes and instead
 often leads to code which is difficult to understand and can contain
-subtly errors, see the `Motivation`_ section for more details.
+subtle errors, see the `Motivation`_ section for more details.
 
 ``None`` is not special enough
 ------------------------------