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

31–40 of 131 posts

Re: PEP 622 – Structural Pattern Matching

#31

Post by tclancy »

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 came to Python after ~5 years of programming in C-style languages (about 15 years ago) and the lack of a switch statement may be the one thing about Python that demonstrably made me a better coder.

When I discovered there wasn't one, I was really annoyed and went digging for an explanation. The one I found was a suggestion if you are reaching for a switch statement, you're (probably) doing something wrong. This is not to impugn anyone else's approach or style and I will freely admit there are times when all you need is a switch and if/ else if/ else gets ugly, but most times I find the replacement for switch is not that but a dictionary holding a callable or similar. I recently showed this approach to a peer in PR and watching it click for her was awesome. She ripped out most of what she'd done and replaced some of our more ponderous permission checking with a dictionary of functions to apply.

I'd say the other thing I do when I wish I had a switch statement is realize I am writing code that is halfway to doing things The Right Way and refactor the block into smaller functions.

Re: PEP 622 – Structural Pattern Matching

#33

Post by lucideer »

nsajko wrote: post #25
lucideer wrote: post #13

Earlier quoted context omitted.

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

When you say "less redundancy", do you just mean terser code? Or what exactly?

I don't see any DRY trade-offs, unless you're talking on a really micro character-count / code-golf level.

Re: PEP 622 – Structural Pattern Matching

#34

Post by BiteCode_dev »

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 prefer the PEP syntax: it looks like the instanciation of the object I'm trying to match, so it makes sense to me.

Re: PEP 622 – Structural Pattern Matching

#35

Post by kevinmgranger »

BiteCode_dev wrote: post #34
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 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.

Re: PEP 622 – Structural Pattern Matching

#36

Post by pizza234 »

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.

Specifically to Ruby (therefore, this is not a generic answer), switch/case has syntax for "short form" expressions, that make the conditionals very coincise, by requiring only the variable part of what would otherwise be, repeating whole expressions.

Making an example is simpler than formulating a defition :-):

  case instance
  when MyClass...
  when MyOtherClass...
  ...
  end
which would otherwise be:

  if instance.is_a?(MyClass)
    ...
  elif instance.is_a?(MyOtherClass)
    ...
  ...
  end
if you consider that this has support for many other expressions (regular expressions, ranges...), you'll see a very coincise construct for the purpose.

Re: PEP 622 – Structural Pattern Matching

#37

Post by BiteCode_dev »

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.

I know.

It doesn't bother me since I see that match/case is a whole different context, I know I'm matching, and have no reason to instanciate anything here.

But since Foo(a=1) looks like instanciation, it's obvious to me what it's supposed to match.

I think that's one of the things that motivated to:

- use new keywords, but existing ones like "as", nor symbols;

- force 2 levels of indentation despite the cost of it.

This makes it very clear, with little effort, that the context is completly different.

It will make scanning the code easy, and avoid confusion.

Re: PEP 622 – Structural Pattern Matching

#38

Post by jfkebwjsbx »

nsajko wrote: post #20
lincolnq wrote: post #14

Earlier quoted context omitted.

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

The point of GP is that the match assumes an equality test and it does it against a single object too.

There is no way in many languages to write an if using a match.

Re: PEP 622 – Structural Pattern Matching

#39

Post by goto11 »

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

Not sure about "increasingly" - note the comment you link to is 15 years old! It seems more like a recognition that map/filter/reduce never was idiomatic Python and there are better ways to do the same. Python have never tried to be a functional language.

Re: PEP 622 – Structural Pattern Matching

#40

Post by lucideer »

krapht wrote: post #19
lucideer wrote: post #13

Earlier quoted context omitted.

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.

These are good examples. Especially for a lower level languages this makes a lot of sense.

For higher level languages, I would imagine typeguards would provide some of the desired functionality here, while being much more lightweight than a full alternative conditional syntax.

Post reply on HN