Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PEP 622 – Structural Pattern Matching

python.org

Post reply on HN
Print view View original

61–70 of 131 posts

Re: PEP 622 – Structural Pattern Matching

#61

Post by uryga »

BiteCode_dev wrote: post #44
uryga wrote: post #3

glad to see this! though it's a shame that the proposed `match/case` is a statement, not an expression: > "We propose the match syntax to be a statement, not an expression. Although in many languages it is an expression, being a statement better suits the general logic of Python syntax." no matching in lambdas unless those get overhauled too :( instead, let's get excited for a whole bunch of this: match x case A: res…

> glad to see this! though it's a shame that the proposed `match/case` is a statement, not an expression: > no matching in lambdas unless those get overhauled too :( Hate it or like it, but it's congruent with the rest of Python design. Guido has been hostile with introducing too much FP in Python. While I find it frustrating from time to time, espacially when I come back from another language to Python, on the long…

what do you think about if-expressions?

  x if cond else y
IMO match-expressions have basically the same benefits/trade-offs.

Re: PEP 622 – Structural Pattern Matching

#62

Post by Tyr42 »

mdrachuk wrote: post #16

So it’s actually a smart switch statement. Seems like it doesn’t create instances when you’re doing Node(children=[Leaf(value="("), Node(), Leaf(value=")")]) instead: 1. Node means "is instance of Node". 2. Everything in between () is "has an attribute with value". 3. List means "the attribute should be treated as a tuple of".. etc.. Very confusing, this definitely needs another syntax, because both newcomers and exp…

I would say it's not a smart switch statement, since you can bind variables.

  match shape:
    case Point(x, y):
        ...
    case Rectangle(x, y, _, _):
        ...
  print(x, y)  # This works

Re: PEP 622 – Structural Pattern Matching

#64

Post by uryga »

pjmlp wrote: post #22
yowlingcat wrote: post #5

Earlier quoted context omitted.

I wonder if this is intentional. FP constructs are increasingly discouraged in Python, taking reduce [1] as an example. Not that this is necessarily a bad thing, per sé -- I think it does simplify the language. But it's an opinionated decision that will discourage FP enthusiasm from finding a home in Python. [1] http://lambda-the-ultimate.org/node/587

With a good mix of comprehensions, itertools, functools and lambda, there is enough stuff to get creative with FP in Python anyway.

btw, my favorite FP-hack: let-in expressions with lambdas OR list comprehensions:

  let x = foo in expr
can be

  [expr for x in (foo,)][0]
(kinda reads like a Haskell `where` clause!) or:

  (lambda x = foo: expr)()
useful in a pre-walrus-operator REPL :)

Re: PEP 622 – Structural Pattern Matching

#65

Post by Tyr42 »

wool_gather wrote: post #55
justusw wrote: post #6

Very interesting. This PEP is still in draft state, but I am interested to see how the community will react. For me, I have a few thoughts: 1) This is really close to Erlang/Elixir pattern matching and will make fail-early code much easier to write and easier to reason about. 2) match/case means double indentation, which I see they reasoned about later in the "Rejected ideas". Might have a negative impact on readabil…

One difference I noticed from Elixir was this: > While matching against each case clause, a name may be bound at most once, having two name patterns with coinciding names is an error. match data: case [x, x]: # Error! ... Which is a bit of a shame. This comes in handy in Elixir to say "the same value must appear at these places in the collection". I.e. for a Python tuple pattern `(x, y, x)`, `(3, 4, 5)` would not mat…

Which equality will you use if it's not numbers, but something more complicated.

What if `(x, y, x)` is matched against some `(a, b, c)` where `a == c`, but not `a is c`? If yes, and you mutate `x` in the body, does it mutate `a` or does it mutate `c`?

I think at least making it an error now can leave it open to defining it later.

Re: PEP 622 – Structural Pattern Matching

#66

Post by CDSlice »

wool_gather wrote: post #55
justusw wrote: post #6

Very interesting. This PEP is still in draft state, but I am interested to see how the community will react. For me, I have a few thoughts: 1) This is really close to Erlang/Elixir pattern matching and will make fail-early code much easier to write and easier to reason about. 2) match/case means double indentation, which I see they reasoned about later in the "Rejected ideas". Might have a negative impact on readabil…

One difference I noticed from Elixir was this: > While matching against each case clause, a name may be bound at most once, having two name patterns with coinciding names is an error. match data: case [x, x]: # Error! ... Which is a bit of a shame. This comes in handy in Elixir to say "the same value must appear at these places in the collection". I.e. for a Python tuple pattern `(x, y, x)`, `(3, 4, 5)` would not mat…

Although it won't be as concise, you can use guards to emulate this feature with

    match data:
        case [x1, x2] if x1 == x2:
            ...
I agree on this being a fantastic addition to the language. I've sorely missed not having pattern matching in Python after using Rust.

Re: PEP 622 – Structural Pattern Matching

#67

Post by BiteCode_dev »

uryga wrote: post #61
BiteCode_dev wrote: post #44

Earlier quoted context omitted.

> glad to see this! though it's a shame that the proposed `match/case` is a statement, not an expression: > no matching in lambdas unless those get overhauled too :( Hate it or like it, but it's congruent with the rest of Python design. Guido has been hostile with introducing too much FP in Python. While I find it frustrating from time to time, espacially when I come back from another language to Python, on the long…

what do you think about if-expressions? x if cond else y IMO match-expressions have basically the same benefits/trade-offs.

Match are usually much more complex than a single ternary condition. Allow to inline them and you will see monsters in the wild.

But I do wish they would have not set aside generalized unpacking.

Re: PEP 622 – Structural Pattern Matching

#68

Post by dragonwriter »

uryga wrote: post #3

glad to see this! though it's a shame that the proposed `match/case` is a statement, not an expression: > "We propose the match syntax to be a statement, not an expression. Although in many languages it is an expression, being a statement better suits the general logic of Python syntax." no matching in lambdas unless those get overhauled too :( instead, let's get excited for a whole bunch of this: match x case A: res…

Just as named functions replace multiline lambdas, I expect that named matcher functions (functions that consist entirely of a match where each arm is a return) will replace match expressions in python.

Abstractly, I'd rather have match expressions, too, but this does fit the rest of Python better.

Re: PEP 622 – Structural Pattern Matching

#69

Post by aparmentier »

Interesting proposal, but I'm cringing at yet another overload for the * symbol.

a * b == "a times b"

a * * b == "a to the power of b"

f(* a) == "call f by flattening the sequence a into args of f"

f(* * a) == "call f by flattening the map a into key value args for f"

[* a] == "match a sequence with 0 or more elements, call them a"

Am I missing something? I know these all occur in different contexts, still the general rule seems to be "* either means something multiplication-y, or means 'having something to do with a sequence' -- depends on the context". It's getting to be a bit much, no?

Note: HN is making me put spaces between * to avoid interpretation as italics.

Post reply on HN