Typos found by codespell (#2073)

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

Author: DimitriPapadopoulos

pep-0002.txt

@@ -67,7 +67,7 @@ Maintainer(s)
 All contributions to the standard library need one or more
 maintainers.  This can be an individual, but it is frequently a group
 of people such as the XML- SIG.  Groups may subdivide maintenance
-tasks among themselves.  One ore more maintainers shall be the *head
+tasks among themselves.  One or more maintainers shall be the *head
 maintainer* (usually this is also the main developer).  Head
 maintainers are convenient people the integrators can address if they
 want to resolve specific issues, such as the ones detailed later in

pep-0042.txt

@@ -106,7 +106,7 @@ Standard Library
   handler, it returns "".  It would be better to make it raise an
   exception (corresponding to EINTR) or to restart.  But these
   changes would have to applied to all places that can do blocking
-  interruptable I/O.  So it's a big project.
+  interruptible I/O.  So it's a big project.
 
   https://bugs.python.org/issue210599
 

pep-0101.txt

@@ -534,7 +534,7 @@ the main repo.
   you will now need to manual remove each blurb entry from
   the ``Misc/NEWS.d/next`` directory that was cherry-picked
   into the release you are working on since that blurb entry
-  is now captured in the merged x.y.z.rst fils for the new
+  is now captured in the merged x.y.z.rst file for the new
   release.  Otherwise, the blurb entry will appear twice in
   the `changelog.html` file, once under `Python next` and again
   under `x.y.z`.

pep-0214.txt

@@ -193,7 +193,7 @@ symbol.
   necessary!  Of course you want the file to be an arbitrary
   expression, not just a single word.  (You definitely want to be
   able to write ``print >>sys.stderr``.)  Without the expression the
-  parser would't be able to distinguish where that expression ends
+  parser wouldn't be able to distinguish where that expression ends
   and where the next one begins, e.g.
 
   ::

pep-0252.txt

@@ -623,7 +623,7 @@ this situation substantially.
 
 - Modification for dynamic types: step 1 and 3 look in the
   dictionary of the type and all its base classes (in MRO
-  sequence, or couse).
+  sequence, or course).
 
 
 Discussion

pep-0287.txt

@@ -271,7 +271,7 @@ SText idea, addressing all of the problems listed above.
 Specification
 =============
 
-The specification and user documentaton for reStructuredText is
+The specification and user documentation for reStructuredText is
 quite extensive.  Rather than repeating or summarizing it all
 here, links to the originals are provided.
 

pep-0340.txt

@@ -270,7 +270,7 @@ Alternatives Considered and Rejected
   an entirely different API than the for-loop, to differentiate
   between the two.  A generator would have to be wrapped in a
   decorator to make it support the block API.  IMO this adds more
-  complexity with very little benefit; and we can't relly deny
+  complexity with very little benefit; and we can't really deny
   that the block-statement is conceptually a loop -- it supports
   break and continue, after all.
 

pep-0367.txt

@@ -481,7 +481,7 @@ The proposal adds a dynamic attribute lookup to the super type, which will
 automatically determine the proper class and instance parameters. Each super
 attribute lookup identifies these parameters and performs the super lookup on
 the instance, as the current super implementation does with the explicit
-invokation of a super instance upon a class and instance.
+invocation of a super instance upon a class and instance.
 
 This proposal relies on sys._getframe(), which is not appropriate for anything
 except a prototype implementation.

pep-0372.txt

@@ -249,7 +249,7 @@ What are the trade-offs of the possible underlying data structures?
      the code a little bit more complex.  All of the basic operations are O(1)
      but the constant factor is increased for __setitem__() and __delitem__()
      meaning that every use case will have to pay for this speedup (since all
-     buildup go through __setitem__). Also, the first traveral incurs a
+     buildup go through __setitem__). Also, the first traversal incurs a
      one-time ``O(n log n)`` sorting cost.  The storage costs are double that
      for the sorted-list-of-keys approach.
 

pep-0374.txt

@@ -1443,7 +1443,7 @@ admitted that svn does not serve the needs of non-committers as well
 as a DVCS does. Because svn only provides its features such as version
 control, branching, etc. to people with commit privileges on the
 repository it can be a hindrance for people who lack commit
-privileges. But DVCSs have no such limitiation as anyone can create a
+privileges. But DVCSs have no such limitation as anyone can create a
 local branch of Python and perform their own local commits without the
 burden that comes with cloning the entire svn repository. Allowing
 anyone to have the same workflow as the core developers was the key