PEP 635: Spelling fixes (#1676)

pep-0635.rst

@@ -115,7 +115,7 @@ that targets *C* by default.
 
 Object oriented programming is geared towards single-dispatch: it is a
 single instance (or the type thereof) that determines which method is to
-be called.  This leads to a somewhat artifical situation in case of binary
+be called.  This leads to a somewhat artificial situation in case of binary
 operators where both objects might play an equal role in deciding which
 implementation to use (Python addresses this through the use of reversed
 binary methods).  Pattern matching is structurally better suited to handle
@@ -198,7 +198,7 @@ established Python structures.  The syntax of patterns following the
 keyword is discussed below.
 
 Given that the case clauses follow the structure of a compound statement,
-the match statement itself naturally becomes a compoung statement itself
+the match statement itself naturally becomes a compound statement itself
 as well, following the same syntactic structure.  This naturally leads to
 ``match <expr>: <case_clause>+``.  Note that the match statement determines
 a quasi-scope in which the evaluated subject is kept alive (although not in
@@ -263,7 +263,7 @@ would fit poorly with Python's statement-oriented nature and lead to
 unusually long and complex expressions and the need to invent new
 syntactic constructs or break well established syntactic rules.  An
 obvious consequence of ``match`` as an expression would be that case
-clauses could no longer have abitrary blocks of code attached, but only
+clauses could no longer have arbitrary blocks of code attached, but only
 a single expression.  Overall, the strong limitations could in no way
 offset the slight simplification in some special use cases.
 
@@ -409,7 +409,7 @@ seen as a prototype to pattern matching in Python, there is only one
 *structural pattern* to express sequences while there is a rich set of
 *binding patterns* to assign a value to a specific variable or field.
 Full pattern matching differs from this in that there is more variety
-in structual patterns but only a minimum of binding patterns.
+in structural patterns but only a minimum of binding patterns.
 
 Patterns differ from assignment targets (as in iterable unpacking) in two ways:
 they impose additional constraints on the structure of the subject, and
@@ -598,7 +598,7 @@ allow you to emulate a switch statement using pattern matching.
 Generally, the subject is compared to a literal pattern by means of standard
 equality (``x == y`` in Python syntax).  Consequently, the literal patterns
 ``1.0`` and ``1`` match exactly the same set of objects, i.e. ``case 1.0:``
-and ``case 1:`` are fully interchangable.  In principle, ``True`` would also
+and ``case 1:`` are fully interchangeable.  In principle, ``True`` would also
 match the same set of objects because ``True == 1`` holds.  However, we
 believe that many users would be surprised finding that ``case True:``
 matched the subject ``1.0``, resulting in some subtle bugs and convoluted
@@ -862,7 +862,7 @@ above.  This precludes, in particular, local variables and global
 variables defined in the current module from acting as constants.
 
 A proposed rule to use a leading dot (e.g.
-``.CONSTANT``) for that purpose was critisised because it was felt that the
+``.CONSTANT``) for that purpose was criticised because it was felt that the
 dot would not be a visible-enough marker for that purpose.  Partly inspired
 by forms found in other programming languages, a number of different
 markers/sigils were proposed (such as ``^CONSTANT``, ``$CONSTANT``,
@@ -917,14 +917,14 @@ iterable.
   'list' notation.  ``[a, b, c]``, ``(a, b, c)`` and ``a, b, c`` are all
   equivalent.  While this means we have a redundant notation and checking
   specifically for lists or tuples requires more effort (e.g.
-  ``case list([a, b, c])``), we mimick iterable unpacking as much as
+  ``case list([a, b, c])``), we mimic iterable unpacking as much as
   possible.
 
 - A starred pattern will capture a sub-sequence of arbitrary length,
   again mirroring iterable unpacking.  Only one starred item may be
   present in any sequence pattern.  In theory, patterns such as ``(*_, 3, *_)``
   could be understood as expressing any sequence containing the value ``3``.
-  In practise, however, this would only work for a very narrow set of use
+  In practice, however, this would only work for a very narrow set of use
   cases and lead to inefficient backtracking or even ambiguities otherwise.
 
 - The sequence pattern does *not* iterate through an iterable subject.  All
@@ -1177,7 +1177,7 @@ universal standards.
 
 It is noteworthy that the concept of pattern matching has always been
 closely linked to the concept of functions.  The different case clauses
-have always been considered as something like semi-indepedent functions
+have always been considered as something like semi-independent functions
 where pattern variables take on the role of parameters.  This becomes
 most apparent when pattern matching is written as an overloaded function,
 along the lines of (Standard ML)::