PEP 622: Change 'target' to 'subject' (#1498)

pep-0622.rst

@@ -169,6 +169,9 @@ The proposed indentation structure is as following::
         case pattern_2:
             ...
 
+Here, `some_expression` represents the value that is being matched against,
+which will be referred to hereafter as the *subject* of the match.
+
 
 Match semantics
 ---------------
@@ -360,7 +363,7 @@ remaining items::
       case (1, x):
           print(f"Got 1 and {x}")
 
-To match a sequence pattern the target must be an instance of
+To match a sequence pattern the subject must be an instance of
 ``collections.abc.Sequence``, and it cannot be any kind of string
 (``str``, ``bytes``, ``bytearray``). It cannot be an iterator. For matching
 on a specific collection class, see class pattern below.
@@ -393,8 +396,8 @@ patterns are allowed in key positions::
       case {constants.DEFAULT_PORT: sub_config, **rest}:
           process_config(sub_config, rest)
 
-The target must be an instance of ``collections.abc.Mapping``.
-Extra keys in the target are ignored even if ``**rest`` is not present.
+The subject must be an instance of ``collections.abc.Mapping``.
+Extra keys in the subject are ignored even if ``**rest`` is not present.
 This is different from sequence pattern, where extra items will cause a
 match to fail. But mappings are actually different from sequences: they
 have natural structural sub-typing behavior, i.e., passing a dictionary
@@ -428,7 +431,7 @@ example::
           ...
 
 Whether a match succeeds or not is determined by the equivalent of an
-``isinstance`` call.  If the target (``shape``, in the example) is not
+``isinstance`` call.  If the subject (``shape``, in the example) is not
 an instance of the named class (``Point`` or ``Rectangle``), the match
 fails.  Otherwise, it continues (see details in the `runtime`_
 section).
@@ -591,7 +594,7 @@ The procedure is as following:
   refuse the temptation to guess."
 
 * If there are any match-by-keyword items the keywords are looked up
-  as attributes on the target.  If the lookup succeeds the value is
+  as attributes on the subject.  If the lookup succeeds the value is
   matched against the corresponding sub-pattern.  If the lookup fails,
   the match fails.
 
@@ -603,7 +606,7 @@ For the most commonly-matched built-in types (``bool``,
 ``frozenset``, ``int``, ``list``, ``set``, ``str``, and ``tuple``), a
 single positional sub-pattern is allowed to be passed to
 the call. Rather than being matched against any particular attribute
-on the target, it is instead matched against the target itself.  This
+on the subject, it is instead matched against the subject itself.  This
 creates behavior that is useful and intuitive for these objects:
 
 * ``bool(False)`` matches ``False`` (but not ``0``).
@@ -1655,11 +1658,11 @@ These customized match behaviors would be controlled by a special
 ``__match__`` method on the class name. There were two competing variants:
 
 * A 'full-featured' match protocol which would pass in not only
-  the target object to be matched, but detailed information about
+  the subject to be matched, but detailed information about
   which attributes the specified pattern was interested in.
-* A simplified match protocol, which only passed in the target object,
+* A simplified match protocol, which only passed in the subject value,
   and which returned a "proxy object" (which in most cases could be
-  just the target) containing the matchable attributes.
+  just the subject) containing the matchable attributes.
 
 Here's an example of one version of the more complex protocol proposed::