diff --git a/pep-0635.rst b/pep-0635.rst index edeec98bc..6bacd6b8a 100644 --- a/pep-0635.rst +++ b/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 : +``. 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)::