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

21–30 of 131 posts

Re: PEP 622 – Structural Pattern Matching

#21

Post by hnlmorg »

quietbritishjim wrote: post #15
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.

The article links to PEP 3103, which is a proposal to add a switch statement to the language. Interestingly, it was written by Guido himself, which you'd usually expect to give a pretty good chance of being accepted, especially since he was the sole decider of what would be accepted at the time! The rejection notice says simply: > A quick poll during my keynote presentation at PyCon 2007 shows this proposal has no po…

I saw that but 'No popular support' doesn't really explain the 'why' part of why Python developers don't want a switch statement.

Re: PEP 622 – Structural Pattern Matching

#22

Post by pjmlp »

yowlingcat wrote: post #5
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…

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.

Re: PEP 622 – Structural Pattern Matching

#23

Post by theelous3 »

jackric wrote: post #9
Narann wrote: post #8

> case Node(children=[LParen(), RParen()]): Is this will create a second Node instance and compare it to node? If so, is it not less efficient performance wise than it's "counterpart" isinstance() + properties comparison? If this method is less efficient, it could be confusing, specially for newcomer. Am I missing something.

It reads like a Node instance construction, but it's actually syntactic sugar for: isinstance(node, Node) and node.children == [LParen(), RParen()]

Is it not more of an

all(hasattr(node, attr) for attr in attrs))

than the ==

Re: PEP 622 – Structural Pattern Matching

#25

Post by nsajko »

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.

Having both switch and if/elif allows writing code with less redundancy in it (unnecessary keywords and variables can be elided by choosing one selection construct over the other).

Re: PEP 622 – Structural Pattern Matching

#29

Post by arusahni »

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/

Re: PEP 622 – Structural Pattern Matching

#30

Post by mumblemumble »

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.

I'm not averse to switch statements in general, but, in Python specifically, I just fail to see the point. In a higher-syntax language like C, a switch statement can save a lot of clutter, and also has some different semantics. In a language like ML, match statements come with a whole lot of extra static checking.

But Python's if/elif/else syntax is already clean enough that there's just not much clutter to remove. And C-style semantics on switch statements wouldn't be acceptable. And Python is a very dynamic language. So, in the end, you would end up with something that's generally the same line count and the same semantics as an equivalent if-statement, meaning it's would be more like semantic Splenda than semantic sugar.

Post reply on HN