iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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

This commit is contained in:
Talin 2020-07-05 21:29:52 -07:00 committed by GitHub
parent 561593f1ff
commit b893d2e02b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 12 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
pep-0622.rst
View File

@ -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::