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

41–50 of 131 posts

Re: PEP 622 – Structural Pattern Matching

#41

Post by BiteCode_dev »

So far I like it.

Unpacking was huge 10 years ago, but nowaday even JS has object destructuring, so python was lagging behind.

It feels like they really spent a lot of time in designing this: Python has clearly not be made for that, and they have to balance legacy design with the new feature.

I think the matching is a success in that regard, and the __match__ method is a great idea. The guards will be handy, while the '_' convention is finally something official. And thanks god for not doing the whole async/await debacle again. Breaking people's code is bad.

On the other hand, I understand the need for @sealed, but this is the kind of thing that shows that Python was not designed with type hints from the begining. Haskell devs must have a laught right now.

We can thank Guido for the PEG parser in 3.9 whichs allows him to co-author this as well.

I expect some ajustments to be made, because we will discover edge cases and performance issues, for sure. Maybe they'll change their mind on generalized unpacking: I do wish to be able to use that for dicts without having to create a whole block.

But all in all, I believe it will be the killer feature of 3.10, and while I didn't see the need to move from 3.7, walrus or not, 3.10 will be my next target for upgrade.

Re: PEP 622 – Structural Pattern Matching

#42

Post by andybak »

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.

Yeah but constantly jumping between idioms means this is stuff I have to usually look up instead of just intuiting.

Re: PEP 622 – Structural Pattern Matching

#43

Post by jjice »

Rust was my first experience with pattern matching, and I really learned to love it there. Seeing it come to Python will be great as well. I'm glad this is on the docket, and I can't wait to see how this draft evolves.

Re: PEP 622 – Structural Pattern Matching

#44

Post by BiteCode_dev »

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 run, I must say I understand.

I don't like to work with FP languages, because unless your team is really good, the code ends up hard to read and debug. It's possible to make very beautiful code in FP, but it makes it so easy to create huge chains of abstract things.

And devs are not reasonable creatures. Give them a gun with 6 bullets, they'll shoot them all, and throw some stones once it's empty.

To me, the average dev is not responsible enought with code quality, and should not be trusted. I'm all for tooling enforcing as much as you can. Linters and formatters help a lot. But sometimes, language design limiting them is a god send.

I've seen the result with Python: you can put a math teacher, a biologist and frontend dev on their first backend project, and they will make something I can stand reading.

Re: PEP 622 – Structural Pattern Matching

#45

Post by LockAndLol »

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…

At first glance I like your suggestion better. It's really distinct from instantiation and won't lead to confusion (imo).

Re: PEP 622 – Structural Pattern Matching

#46

Post by vslira »

This is great. I'm currently trying to rewrite a heavily object-oriented library into a more functional one (the rewrite is necessary because of licensing issues, and functional because the original code is a clusterf*ck of mutation) and despite the whole company working on top of Python, I was seriously considering implementing it in SML[1] specifically due to pattern matching making the underlying algorithm of the main data structure incredibly easier to reason about and implement.

[1] Yes I know coconut-lang is a thing, but I didn't want to introduce something that looks a lot like Python but isn't in our codebase

Re: PEP 622 – Structural Pattern Matching

#47

Post by bjourne »

hnlmorg wrote: post #12

Can someone explain to me the history behind Python's aversion to switch statements? I get Python is opinionated and I'm not trying to start a language war, it was just never clear to me why the `if ... elif` pattern was the preferred idiom.

Case statements are an anti-pattern. The proper way to implement that design pattern is using either dispatch dictionaries or plain-old polymorphism.

Re: PEP 622 – Structural Pattern Matching

#48

Post by hombre_fatal »

kevinmgranger wrote: post #35
BiteCode_dev wrote: post #34

Earlier quoted context omitted.

I prefer the PEP syntax: it looks like the instanciation of the object I'm trying to match, so it makes sense to me.

That's their entire point: you're _not_ instantiating the object you're trying to match.

And the counter-point is: you learn one time that it's not instantiation and remember it forever, and you get to resume reusing/overloading muscle-memory syntax to get the job done.

Re: PEP 622 – Structural Pattern Matching

#50

Post by andreareina »

lucideer wrote: post #13
hnlmorg wrote: post #12

Can someone explain to me the history behind Python's aversion to switch statements? I get Python is opinionated and I'm not trying to start a language war, it was just never clear to me why the `if ... elif` pattern was the preferred idiom.

Taking this question from the opposite angle, what benefits do switch statements give us over if...elif? Not actually a heavy Python user, but even though most languages I use regularly are more switch/case-heavy, I've never quite grasped why there's two largely interchangeable ways to do the one thing.

Switch might "just" be a special case (har har) of if/elif, but it's a significant one: where you're branching only on the value of one variable, and branching on equality. I'd say it's significant enough to merit some special syntax.

To put it another way: when you're branching on the value of a single variable by comparing it to an enumerated set of values, the obvious way to do so is with switch/case.

Post reply on HN