diff --git a/peps/pep-0810.rst b/peps/pep-0810.rst
index 4345a94a1b1..7ba51f8d3f9 100644
--- a/peps/pep-0810.rst
+++ b/peps/pep-0810.rst
@@ -1443,7 +1443,7 @@ Alternate keyword names
 -----------------------
 
 For this PEP, we decided to propose ``lazy`` for the explicit keyword as it
-felt the most familar to those already focused on optimizing import overhead.
+felt the most familiar to those already focused on optimizing import overhead.
 We also considered a variety of other options to support explicit lazy
 imports. The most compelling alternates were ``defer`` and ``delay``.
 
@@ -1541,14 +1541,14 @@ imports), there was a suggestion to add a way to override the global disable
 and force particular imports to be lazy, for instance by calling the lazy
 imports filter even if lazy imports are globally disabled.
 
-This approach could a complex hierarchy of the different "override" systems,
-making it much harder to analyze and reason about the code. Additionally,
-this may require additional complexity to introduce finer-grained systems to
-enable or disable particular imports as the use of lazy imports evolves. The
-global disable is not expected to see commonplace use, but be more of a
-debugging and selective testing tool for those who want to tightly control
+This approach could introduce a complex hierarchy of the different "override"
+systems, making it much harder to analyze and reason about the code.
+Additionally, this may require additional complexity to introduce finer-grained
+systems to enable or disable particular imports as the use of lazy imports
+evolves. The global disable is not expected to see commonplace use, but be more
+of a debugging and selective testing tool for those who want to tightly control
 their dependency on lazy imports. We think it's reasonable for package
-mantainers, as they update packages to adopt lazy imports, to decide to
+maintainers, as they update packages to adopt lazy imports, to decide to
 *not* support running with lazy imports globally disabled.
 
 It may be that this means that in time, as more and more packages embrace
@@ -1573,7 +1573,7 @@ has been proposed:
 This would replace the need for :data:`!__lazy_modules__`, and allow
 libraries to use one of the existing lazy imports implementations in older
 Python versions. However, adding magic ``with`` statements with that kind of
-effect would be a signficant change to Python and ``with`` statements in
+effect would be a significant change to Python and ``with`` statements in
 general, and it would not be easy to combine with the implementation for
 lazy imports in this proposal. Adding standard library support for existing
 lazy importers *without* changes to the implementation amounts to the status