Fix some typos (without, I trust, changing any of the semantics)

pep-0252.txt

@@ -62,7 +62,7 @@ Introspection APIs
     Classes have a __dict__ attribute, which yields a dictionary
     containing methods and class variables defined by the class
     itself, and a __bases__ attribute, which is a tuple of base
-    classes that must be inspected recursively.  Some assumption here
+    classes that must be inspected recursively.  Some assumptions here
     are:
 
     - attributes defined in the instance dict override attributes
@@ -87,15 +87,15 @@ Introspection APIs
     __members__ attribute, if present, is a list of data attribute
     names supported by the object.
 
-    The type API is sometimes combined by a __dict__ that works the
-    same was as for instances (for example for function objects in
+    The type API is sometimes combined with a __dict__ that works the
+    same as for instances (for example for function objects in
     Python 2.1, f.__dict__ contains f's dynamic attributes, while
     f.__members__ lists the names of f's statically defined
     attributes).
 
     Some caution must be exercised: some objects don't list theire
     "intrinsic" attributes (like __dict__ and __doc__) in __members__,
-    while others do; sometimes attribute names that occur both in
+    while others do; sometimes attribute names occur both in
     __members__ or __methods__ and as keys in __dict__, in which case
     it's anybody's guess whether the value found in __dict__ is used
     or not.
@@ -220,7 +220,7 @@ Specification of the class-based introspection API
        A meta-object may have a __bases__ attribute.  If it does, this
        should be a sequence (not necessarily a tuple) of other
        meta-objects, the bases.  An absent __bases__ is equivalent to
-       an empty sequece of bases.  There must never be a cycle in the
+       an empty sequence of bases.  There must never be a cycle in the
        relationship between meta-objects defined by __bases__
        attributes; in other words, the __bases__ attributes define an
        directed acyclic graph.  (It is not necessarily a tree, since
@@ -246,7 +246,7 @@ Specification of the class-based introspection API
        otherwise (if there is no __set__ method) the dynamic attribute
        has precedence.
 
-       Rationale: we can't have a simples rule like "static overrides
+       Rationale: we can't have a simple rule like "static overrides
        dynamic" or "dynamic overrides static", because some static
        attributes indeed override dynamic attributes; for example, a
        key '__class__' in an instance's __dict__ is ignored in favor

pep-0253.txt

@@ -27,7 +27,7 @@ Introduction
     the type does not implement the specific behavior; in that case
     the system may provide a default behavior in that case or raise an
     exception when the behavior is invoked.  Some collections of
-    functions pointers that are usually defined together are obtained
+    function pointers that are usually defined together are obtained
     indirectly via a pointer to an additional structure containing
     more function pointers.
 
@@ -49,7 +49,7 @@ Introduction
         practical -- you still can't multiply inherit from list and
         dictionary)
 
-      - the standard coercions functions (int, tuple, str etc.) will
+      - the standard coercion functions (int, tuple, str etc.) will
         be redefined to be the corresponding type objects, which serve
         as their own factory functions
 
@@ -240,7 +240,7 @@ Making a type a factory for its instances
     the tp_new() slot and the tp_init() slot lies in the invariants
     they ensure.  The tp_new() slot should ensure only the most
     essential invariants, without which the C code that implements the
-    object's wold break.  The tp_init() slot should be used for
+    object's would break.  The tp_init() slot should be used for
     overridable user-specific initializations.  Take for example the
     dictionary type.  The implementation has an internal pointer to a
     hash table which should never be NULL.  This invariant is taken
@@ -251,7 +251,7 @@ Making a type a factory for its instances
 
     Note that for immutable object types, the initialization cannot be
     done by the tp_init() slot: this would provide the Python user
-    with a way to change the initialiation.  Therefore, immutable
+    with a way to change the initialization.  Therefore, immutable
     objects typically have an empty tp_init() implementation and do
     all their initialization in their tp_new() slot.
 
@@ -318,7 +318,7 @@ Making a type a factory for its instances
     standard heap and initializes it properly.  It uses the above
     formula to determine the amount of memory to allocate, and takes
     care of GC registration.  The only reason not to use this
-    implementation would be to allocate objects from different heap
+    implementation would be to allocate objects from a different heap
     (as is done by some very small frequently used objects like ints
     and tuples).  PyType_GenericNew() adds very little: it just calls
     the type's tp_alloc() slot with zero for nitems.  But for mutable
@@ -379,7 +379,7 @@ Preparing a type for subtyping
 
         void tp_free(PyObject *object)
 
-    (In a previous version of this PEP, there was also role reserved
+    (In a previous version of this PEP, there was also a role reserved
     for the tp_clear() slot.  This turned out to be a bad idea.)
 
     To be usefully subtyped in C, a type must export the structure
@@ -530,7 +530,7 @@ Subtyping in Python
         def method1(self): pass
         # etc.
 
-    The body of the class statement is executes in a fresh environment
+    The body of the class statement is executed in a fresh environment
     (basically, a new dictionary used as local namespace), and then C
     is created.  The following explains how C is created.