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

11–20 of 131 posts

Re: PEP 622 – Structural Pattern Matching

#11

Post by uryga »

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

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, on the other hand, do think it's a bad thing :) but what can you do...

Re: PEP 622 – Structural Pattern Matching

#12

Post by hnlmorg »

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.

Re: PEP 622 – Structural Pattern Matching

#13

Post by lucideer »

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.

Re: PEP 622 – Structural Pattern Matching

#14

Post by lincolnq »

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 think culturally, because “explicit is better than implicit” (from the Zen of Python). Switch statements have a lot of implicit-ness to them (implicit invocation of equality comparison, to start) and it never seemed quite necessary, given how spare Python syntax is anyway.

Re: PEP 622 – Structural Pattern Matching

#15

Post by quietbritishjim »

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 popular support. I therefore reject it.

[1] https://www.python.org/dev/peps/pep-3103/

Re: PEP 622 – Structural Pattern Matching

#16

Post by mdrachuk »

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 experienced devs will be prone to read it as plain `==`, since that's how enums and primitives will be working.

This syntax goes against Zen: It’s implicit -- when using match case expressions don't mean what they regularly mean. It’s complicated -- basically it’s another language (like regex) which is injected into Python.

I’m a big believer in this feature, it just needs some other syntax. Using {} instead of () makes it a lot better. Now no way to confuse it with simple equality.

  match node:
    case Node{children=[{Leaf{value="(", Node{}, ...}}

Re: PEP 622 – Structural Pattern Matching

#18

Post by lincolnq »

This is very exciting!

One subtle thing which I noticed is the distinction between class patterns and name patterns (bindings). In particular, it is possibly confusing that the code `case Point:` matches anything and binds it to the value Point, whereas `case Point():` checks if the thing is an instance of Point and doesn’t bind anything.

Re: PEP 622 – Structural Pattern Matching

#19

Post by krapht »

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.

In lower level languages, when you use switch, you make it easier for the compiler to generate a jump table.

In higher level langues with strong, static types, the switch statement can indicate to the compiler you want to match on the type of the variable; it can do analysis then to make sure your pattern match is exhaustive.

Re: PEP 622 – Structural Pattern Matching

#20

Post by nsajko »

lincolnq wrote: post #14
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 think culturally, because “explicit is better than implicit” (from the Zen of Python). Switch statements have a lot of implicit-ness to them (implicit invocation of equality comparison, to start) and it never seemed quite necessary, given how spare Python syntax is anyway.

You choose to interpret a switch statement through an if statement, but that's arbitrary: the other way around is also possible (interpreting/rewriting an if-else construction as switch statements).
Post reply on HN