Issue #27895: Spelling fixes (Contributed by Ville Skyttä).

5 files changed, 5 insertions, 5 deletions

diff --git a/Objects/bytearrayobject.c b/Objects/bytearrayobject.c
index 1458635..6d4c6a1 100644
--- a/Objects/bytearrayobject.c
+++ b/Objects/bytearrayobject.c
@@ -506,7 +506,7 @@ bytearray_setslice_linear(PyByteArrayObject *self,
 
                If growth < 0 and lo != 0, the operation is completed, but a
                MemoryError is still raised and the memory block is not
-               shrinked. Otherwise, the bytearray is restored in its previous
+               shrunk. Otherwise, the bytearray is restored in its previous
                state and a MemoryError is raised. */
             if (lo == 0) {
                 self->ob_start += growth;
diff --git a/Objects/codeobject.c b/Objects/codeobject.c
index 964ae62..6c0e5bf 100644
--- a/Objects/codeobject.c
+++ b/Objects/codeobject.c
@@ -718,7 +718,7 @@ _PyCode_CheckLineNumber(PyCodeObject* co, int lasti, PyAddrPair *bounds)
     /* possible optimization: if f->f_lasti == instr_ub
        (likely to be a common case) then we already know
        instr_lb -- if we stored the matching value of p
-       somwhere we could skip the first while loop. */
+       somewhere we could skip the first while loop. */
 
     /* See lnotab_notes.txt for the description of
        co_lnotab.  A point to remember: increments to p
diff --git a/Objects/listsort.txt b/Objects/listsort.txt
index 832e4f2..152a270 100644
--- a/Objects/listsort.txt
+++ b/Objects/listsort.txt
@@ -694,7 +694,7 @@ search doesn't reduce the quadratic data movement costs.
 
 But in CPython's case, comparisons are extraordinarily expensive compared to
 moving data, and the details matter.  Moving objects is just copying
-pointers.  Comparisons can be arbitrarily expensive (can invoke arbitary
+pointers.  Comparisons can be arbitrarily expensive (can invoke arbitrary
 user-supplied Python code), but even in simple cases (like 3 < 4) _all_
 decisions are made at runtime:  what's the type of the left comparand?  the
 type of the right?  do they need to be coerced to a common type?  where's the
diff --git a/Objects/longobject.c b/Objects/longobject.c
index cd04e36..9b62d92 100644
--- a/Objects/longobject.c
+++ b/Objects/longobject.c
@@ -368,7 +368,7 @@ PyLong_FromDouble(double dval)
 /* Checking for overflow in PyLong_AsLong is a PITA since C doesn't define
  * anything about what happens when a signed integer operation overflows,
  * and some compilers think they're doing you a favor by being "clever"
- * then.  The bit pattern for the largest postive signed long is
+ * then.  The bit pattern for the largest positive signed long is
  * (unsigned long)LONG_MAX, and for the smallest negative signed long
  * it is abs(LONG_MIN), which we could write -(unsigned long)LONG_MIN.
  * However, some other compilers warn about applying unary minus to an
diff --git a/Objects/typeobject.c b/Objects/typeobject.c
index 1181d77..ccde3de 100644
--- a/Objects/typeobject.c
+++ b/Objects/typeobject.c
@@ -3759,7 +3759,7 @@ import_copyreg(void)
     /* Try to fetch cached copy of copyreg from sys.modules first in an
        attempt to avoid the import overhead. Previously this was implemented
        by storing a reference to the cached module in a static variable, but
-       this broke when multiple embeded interpreters were in use (see issue
+       this broke when multiple embedded interpreters were in use (see issue
        #17408 and #19088). */
     copyreg_module = PyDict_GetItemWithError(interp->modules, copyreg_str);
     if (copyreg_module != NULL) {