Re: PEP 622: Structural Pattern Matching
I really dislike the fact that case with is instance check looks like instantiation. case Node(children=[…]) Along with checks for int or enum cases, "is instance” and attribute checks like the one above will be perceived as equality check. Basically what happens is based on context the round brackets () next to the class name mean different things, which will confuse people a lot. If instead the curly brackets {}were used for "match checks” the code would be more explicit about not being an equality check: case Node{children=[…]}
I had another thought about a way to make the bound names explicit. # Keyword case Point(x -> px, y -> py): # Positional case Point(-> x, -> y): # Sub-pattern, positional case Line(Point() -> p1, Point() -> p2): # Sub-pattern, keyword case Line(start: Point() -> p1, end: Point() -> p2): -- Greg
On 2020-06-25 04:54, Greg Ewing wrote:
I had another thought about a way to make the bound names explicit.
# Keyword case Point(x -> px, y -> py):
# Positional case Point(-> x, -> y):
# Sub-pattern, positional case Line(Point() -> p1, Point() -> p2):
# Sub-pattern, keyword case Line(start: Point() -> p1, end: Point() -> p2):
How do you indicate that you want it to match anything and don't care about the value?
On 26/06/20 5:07 am, MRAB wrote:
How do you indicate that you want it to match anything and don't care about the value?
case Spam(-> _): Or if that's considered too verbose and we're willing to make _ even more special, it could be just case Spam(_): In that case we would be regarding _ as a "value that matches anything" rather than a "name that doesn't get assigned to". -- Greg
participants (3)
-
Greg Ewing -
Misha Drachuk -
MRAB