PEP 622: minor word additions/changes (#1453)
This commit is contained in:
parent
64b943aaf4
commit
9a895d7dce
10
pep-0622.rst
10
pep-0622.rst
|
@ -473,7 +473,7 @@ Guards
|
|||
|
||||
Each *top-level* pattern can be followed by a guard of the form
|
||||
``if expression``. A case clause succeeds if the pattern matches and the guard
|
||||
evaluates to true value. For example::
|
||||
evaluates to a true value. For example::
|
||||
|
||||
match input:
|
||||
case [x, y] if x > MAX_INT and y > MAX_INT:
|
||||
|
@ -818,7 +818,7 @@ this example::
|
|||
target: str
|
||||
value: Expression
|
||||
|
||||
@dataclasses
|
||||
@dataclass
|
||||
class Print(Statement):
|
||||
value: Expression
|
||||
|
||||
|
@ -843,7 +843,7 @@ Type erasure
|
|||
|
||||
Class patterns are subject to runtime type erasure. Namely, although one
|
||||
can define a type alias ``IntQueue = Queue[int]`` so that a pattern like
|
||||
``IntQueue()`` is syntactically valid, type checkers should rejected such
|
||||
``IntQueue()`` is syntactically valid, type checkers should reject such a
|
||||
match::
|
||||
|
||||
queue: Union[Queue[int], Queue[str]]
|
||||
|
@ -1056,9 +1056,9 @@ A small collection of example code is
|
|||
Rejected Ideas
|
||||
==============
|
||||
|
||||
This general idea was floating around for pretty long time, and many
|
||||
This general idea has been floating around for a pretty long time, and many
|
||||
back and forth decisions were made. Here we summarize many alternative
|
||||
paths that were taken, but abandoned after all.
|
||||
paths that were taken but eventually abandoned.
|
||||
|
||||
Don't do this, pattern matching is hard to learn
|
||||
------------------------------------------------
|
||||
|
|
Loading…
Reference in New Issue