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

81–90 of 131 posts

Re: PEP 622 – Structural Pattern Matching

#81

Post by uryga »

BiteCode_dev wrote: post #67
uryga wrote: post #61

Earlier quoted context omitted.

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.

> Allow to inline them and you will see monsters in the wild.

idk... you can write a huge ugly if-elif-else like this:

  a if foo else b if bar else c if quux else d
but most people just don't.

Re: PEP 622 – Structural Pattern Matching

#82

Post by [deleted] »

uryga wrote: post #81
BiteCode_dev wrote: post #67

Earlier quoted context omitted.

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.

> Allow to inline them and you will see monsters in the wild. idk... you can write a huge ugly if-elif-else like this: a if foo else b if bar else c if quux else d but most people just don't.

[deleted]

Re: PEP 622 – Structural Pattern Matching

#83

Post by heavenlyblue »

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.

Ternary expressions are not covered by python code coverage tools by the way.

Re: PEP 622 – Structural Pattern Matching

#84

Post by heavenlyblue »

uryga wrote: post #64
pjmlp wrote: post #22

Earlier quoted context omitted.

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

If you want to program in Haskell, why don’t you get a job programming in Haskell rather than inventing something so ugly?

You would not get through code review with that in any shop that has discipline.

Re: PEP 622 – Structural Pattern Matching

#85

Post by heavenlyblue »

duckerude wrote: post #72
aparmentier wrote: post #69

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 genera…

It's already used that way for unpacking, e.g. >>> [x, *other] = range(10) >>> x 0 >>> other [1, 2, 3, 4, 5, 6, 7, 8, 9] So this instance of the syntax is not that novel. If it's a mistake, it's too late to fix it. A unary asterisk before a name means the name represents a sequence of comma-separated items. If it's a name you're assigning to (LHS) that means packing the sequence into the name, if it's a name you're r…

You can also do [a, * b] when constructing a list so that b would be injected into that list after a - makes total sense.

Re: PEP 622 – Structural Pattern Matching

#86

Post by JNRowe »

csantini wrote: post #32

If you want it today, Pampy does most of it: https://github.com/santinic/pampy Even match on Point(x, y, _)

There is also switchlang¹ which isn't quite the same thing, but provides some of the functionality of PEP-622 and pampy. I believe it is notable for including a nice descriptive README, and also having a small/simple implementation.

I personally prefer the pampy internals, but quite like the context manager usage from switchlang. I don't even know which bikeshed I want to paint, let alone the colour.

1. https://github.com/mikeckennedy/python-switch

Re: PEP 622 – Structural Pattern Matching

#87

Post by RhysU »

CDSlice wrote: post #66
wool_gather wrote: post #55

Earlier quoted context omitted.

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.

Guards feel superfluous if the x, x pattern can be trivially lowered into a guard.

Re: PEP 622 – Structural Pattern Matching

#88

Post by qorrect »

andolanra wrote: post #74
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…

It's worth noting that there's a truly massive amount of precedent in other languages for Python implementing it using the syntax as proposed. Languages that have or are planning to include pattern-matching where the pattern syntax exactly mirrors the expression syntax like this include Rust, Swift, OCaml, Haskell, C++, Ruby, Erlang, and many, many more. I understand the worry that newcomers might struggle, but I don…

Yes I think thats what the original commenter was missing. Pattern matching is not new ( but it is awesome ), there are already expectations of how it would look in Python.

I can't wait for this feature!

Re: PEP 622 – Structural Pattern Matching

#89

Post by herman_toothrot »

arusahni wrote: post #29
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…

What's interesting here is this is gated on the new parser from PEP-617 [1]. Based on mailing list discussions [2], and the PEP, the use of `match` will be context-sensitive, so it shouldn't be as disruptive of an introduction as `async`. 1: https://www.python.org/dev/peps/pep-617/ 2: https://lwn.net/Articles/816922/

missed a zero: https://www.python.org/dev/peps/pep-0617/

Re: PEP 622 – Structural Pattern Matching

#90

Post by adamnew123456 »

uryga wrote: post #11
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

the Syntax section has a bit more: > "[...] making it an expression would be inconsistent with other syntactic choices in Python. All decision making logic is expressed almost exclusively in statements, so we decided to not deviate from this." so it's just keeping in line with Python's general imperativess. > FP constructs are increasingly discouraged in Python [...] Not that this is necessarily a bad thing, per sé i…

> i, on the other hand, do think it's a bad thing :) but what can you do...

Hy[1] I guess? It looks pretty lively although I'm not sure how seriously people take it these days.

[1]: https://github.com/hylang/hy

Post reply on HN