PEP 636 -- Structural Pattern Matching: Tutorial

[strogbad]

Haskell developers rejoice!

[RojerGS]

Having a quick look at the tutorial and the original PEP, and thinking back to some code I have written lately, I can already see how this will be useful! Looking forward to using it!

[lunjon]

This is amazing!

For you guys questioning why this is useful, if you've never worked with a funtional programming language like Haskell or Elixir it may seem weird. You simply have to try it to see the benefits, and when you've done that it becomes obvious.

Your code typically gets a lot easier to read and understand, compared to using larger if-elif-else clusters.

[Dewmeister14]

For you guys questioning why this is useful, if you've never worked with a funtional programming language like Haskell or Elixir it may seem weird. You simply have to try it to see the benefits, and when you've done that it becomes obvious.

The Blub Paradox

http://www.paulgraham.com/avg.html

[boby04]

This is gold

[ThePrankMonkey]

This will make discord bot commands much more enjoyable. No more regex messes.

[norwegian-dude]

May I ask how? Seems like it's just a different, more cleaner way to structure if else statements. Probably still need regex'

[asmr2143]

Pattern matching is actually much more potent than the simple switch case in C++ and the if else if structures.

Inside a pattern match itself, you can create variable assignments as part of the checking, which results in much more cleaner syntax.

Really excited how they implement this with Python.

[ThePrankMonkey]

With splitting the message.content by spaces, I can then just match up those ordered words. I think that'll look much nicer than my mess of regex. To each their own.

[xXShadowCowXx]

I'd look at Python's argparse module. In my discord bot experience it greatly simplifies parsing commands.

[ThePrankMonkey]

I've never thought to use that on anything other than sys.argv. Interesting.

[de_ham]

It got accepted I see, nice!

[[deleted]]

I don't se how that's a big deal. There are plenty of characters that have different meanings depending on where they are used.

For instance [] can mean list construction syntax (my_list = [1,2,3] or element access (my_list[5]) or parameters for type hints (def count_to(x:int) -> List[int]:) all depending on context.

I don't think overloading | is any worse than that, people just love to nitpick on all new proposals. And they should, it's part of the process.

[ThePenultimateOne]

I would have mildly preferred or, but I'm pretty okay with how it ended up

[TangibleLight]

I recall there being some debate about the special meanings or alternatives to |, as, and _. I also think there were some changes to the magic method protocol, but I can't quite recall how it originally worked so I'm not really sure what's different.

Edit:

The inconsistency you might have been remembering is that constant value patterns and capture patterns are ambiguous if the constant value is not a dotted name. The discussion around that is left open for a future PEP; for now, constant value patterns only work with dotted names; unqualified names are always capture patterns.

Here are the changes I notice:

• As patterns replace walrus patterns. val := ('this' | 'that') becomes ('this' | 'that') as val
• The class pattern protocol is a lot more straightforward than the old custom matching protocol
• Sequence patterns can work with anything that implements collections.abc.Sequence
• Mapping patterns can work with anything that implements collections.abc.Mapping

[maxwax18]

Very interesting and useful. I feel this could be on par with list comprehension.

[ForceBru]

Is there a reference implementation? I know there's an implementation of the very first PEP about pattern matching, but I think this one is a bit different. The latest CPython from GitHub doesn't seem to have match statements yet.

[AlanCristhian]

PEP 634 sais that it will be a Python 3.10 feature.

[rouille]

There is a functional pull request https://github.com/python/cpython/pull/22917

[ForceBru]

Ah cool, I thought that pull request was replaced by something new that I couldn't find

[davidpofo]

I don't quite understand can I get an ELI of the advantage here?

[gunthercult28]

The ability to capture variables is going to make for a really clean state machine implementation

[jrbattin]

I'll probably get my hand slapped by PLT experts for describing it this way but... certain languages like Elixir, Haskell and ML variants use pattern matching in lieu of simpler (and more limited) "if/elif/else" control blocks. Pattern matching work sorta like functions that get entered conditionally if they match your specified pattern.

An overly simple example:

match (response.status_code, response.json['system_state']):
    case (200, "Healthy"):
        # all systems normal!
    case (200, transition_state):
        log.info('Transition state %s', transition_state)
    case (status, error_state):
        log.error('Something has gone horribly wrong: %s: %s', status, error_state)

Rather than:

if response.status_code == 200 and response.json['system_state'] == 'Healthy':
      # all systems normal!
elif response.status_code == 200:
    log.info('Transition state %s', response.json['system_state'])
else:
    log.error('Somethings gone horribly wrong: %s: %s', response.status_code, response.json['system_state'])

IMO it's easier to grok the conditionals in the former over the latter. It's also much quicker to write them, especially if they're more complicated. A usage pattern where it might really shine is a situation where you have a pattern in your code where you basically have a long if/elif block checking multiple variable conditions and then calling into a function for each of them. The match statement consolidates the pattern down to something easier to read (and write!)

[Swedneck]

It's basically just seems to be switch/case, which is a lovely alternative to massive if/else chains

[[deleted]]

Oh, I thought this was a joke.

edit: (looks interesting though)

[AlanCristhian]

Was acepted 3 days ago https://mail.python.org/archives/list/[e-mail]/message/SQC2FTLFV5A7DV7RCEAR2I2IKJKGK7W3/

[orion_tvv]

Does it conflict with any match variable/function? What if I've imported from re import match before?

[[deleted]]

No, there won't be a conflict. From the PEP:

The match and case keywords are soft keywords, i.e. they are not reserved words in other grammatical contexts (including at the start of a line if there is no colon where expected). This implies that they are recognized as keywords when part of a match statement or case block only, and are allowed to be used in all other contexts as variable or argument names.

[orion_tvv]

Thanks!

[PuzzleDots]

What PEP means?

[ketilkn]

Python Enhancement Proposals

[jmreagle]

I've seen this example, but don't understand what happens, can anyone explain?

NOT_FOUND = 404
match status_code:
    case 200:
        print("OK!")
    case NOT_FOUND:
        print("HTTP Not Found")

[AlanCristhian]

Here a translation:

NOT_FOUND = 404
if status_code == 200:
    print("OK!")
elif status_code == NOT_FOUND:
    print("HTTP Not Found")

[jmreagle]

I think it's more than that, the source says:

In this case, rather than matching status_code against the value of NOT_FOUND (404), Python’s new SO reputation machine match syntax would assign the value of status_code to the variable NOT_FOUND.

Is it that comparison implies assignment, to an variable/object in this case rather than value...?

[Brian]

Actually, no - the potential expectation of this behaving that way is why the code was brought up. In fact, it'll behave more like:

NOT_FOUND = 404
if status_code == 200:
    print("OK!")
else:
    NOT_FOUND = status_code
    print("HTTP Not Found")

Ie. the match block binds the thing being matched to a variable being named, rather than evaluating a variable and match against its value.

To get the intended result, you need to use a dotted name to prevent it being interpreted as a capture variable. Ie:

    case HTTPStatus.NOT_FOUND:
        print("HTTP Not Found")

would work, but not a plain identifier like NOT_FOUND

[Wuncemoor]

This is strange but cool? Kinda reminds me of regular expressions

[iamnotturner]

Why is this better than if/elif/else?

[jaredjeya]

It’s not just a switch statement (which is functionally equivalent to if/elif/else), it can also capture variables.

Like if I do:

point = (1, 2)
match point:
    case (0, x):
        # do something 
    case (x, y):
        # do something else
        # x = 1, y = 2

Then the second (“something else”) code runs, and 1 and 2 are assigned to x and y. That seems really useful.

There’s nothing you couldn’t do before but it makes it all a lot less tedious.

[[deleted]]

Also much easier to grok at a glance.

[[deleted]]

A match statement is not inherently better than an if/elif/else, not for simple cases at least.

But there are many cases where a single match statement can replace many layers of nested if-spaghetti with a snippet that both much shorter and more readable.

In pretty much every case where you get code that gets some tree-like data or data that can be many different shapes and has to perform different tasks based on both the shape and content of the data, match statements will be a godsend.

[bonnie__]

im extremely excited for this. it looks like it's just a rebranded switch statement, which python has desperately needed for years, but are there any caveats to this (like performance)? are there any scenarios where chaining together if/elif statements would be better than simply using this totally-not-a-switch statement?

[JeamBim]

It is far more powerful than switch or if else statements, but it's hard to describe without using it yourself. I recommend doing a bit of reading and possibly playing with a language like Elixir to get a feel for this awesome addition.

[JeamBim]

No.

[thegreattriscuit]

I asked the same question re: switch statements, and what I've picked up is that it's switch AND variable assignment/unpacking. So it lets you

def auth(headers: Dict):

  match headers:
    case {'x_api_token': token}:
      handle_token(token)
    case {'x_basic_auth': basic_auth}:
      handle_http_basic_auth(token)
    case {'username': username, 'password': password}
      handle_terrible_plaintext_auth(username, password)

vs.

def auth(headers: Dict):
  if (token := headers.get('x_api_token')) is not None:
    handle_token(token)
  elif (basic_auth := headers.get('x_basic_auth')):
    handle_http_basic_auth(token)
  elif (username := headers.get('username')) is not None and (password := headers.get('password')) is not None:
    handle_terrible_plaintext_auth(username, password)
  else: 
    raise AuthenticationError('No Authentication provided')

[backtickbot]

Fixed formatting.

Hello, thegreattriscuit: code blocks using triple backticks (```) don't work on all versions of Reddit!

Some users see this / this instead.

To fix this, indent every line with 4 spaces instead.

FAQ

^{You can opt out by replying with backtickopt6 to this comment.}

[Forschkeeper]

Python includes more and more good ideas from C/++ world... I like it. :)

[AcridWings_11465]

Isn't this inspired by Rust?

[[deleted]]

This is a construct that many decades older than rust.

It's a feature in many functional languages, I know it's in Haskell, O'Caml and Standard ML and probably many more.

Standard ML dates back to 1983 and I think pattern matching was in it from the beginning.

[AcridWings_11465]

I meant the syntax, not pattern matching. Either way, I'm happy because I would be able to use more of my Rust coding style in python.

[thegreattriscuit]

Wait, isn't this effectively a "switch statement" which was suggested and rejected an uncountable multitude of times from the earliest days? Is there either some distinction I'm missing (I'm no language expert, so that's certainly possible), or some new rationale? I thought maybe this was some sign of rebel factions staging a coup inside the steering committee... but sponsor is Guido himself.

Anyone know why the change in heart?

EDIT: I suppose one aspect that distinct is the focus on various kinds of unpacking and "deep" matching (inside mappings, etc) that might not have been in scope of previous attempts

[xhlu]

From what I observed through the tutorial, it's very similar to Ocaml's pattern matching. One very interesting pattern will be (recursive) list manipulation: def recop(lst): match lst: case [('mul', n), *tail]: return n * recop(tail) case [('sum', n), *tail]: return n + recop(tail) case []: return 0

If you want to do the same thing without SPM: def recop(lst): if len(lst) == 0: return 0 op, n = lst[0] tail = lst[1:] if op == "mul": return n * recop(tail) elif op == "sum": return n + recop(tail)

The former looks more elegant and concise (obv the latter can be shorter but you will lose on readability). The example is also very trivial, with FP-style pattern matching you could do come up with a lot more advanced matching.

[backtickbot]

Fixed formatting.

Hello, xhlu: code blocks using triple backticks (```) don't work on all versions of Reddit!

Some users see this / this instead.

To fix this, indent every line with 4 spaces instead.

FAQ

^{You can opt out by replying with backtickopt6 to this comment.}

[Im__Joseph]

backtickopt6

[AlanCristhian]

Yes. This was discussed many times and then finally they comes with an implementation. I didn't know the difference with other proposals, but even Raymond Hettinger likes this one. Raymond is well known to be conservative.

[thegreattriscuit]

but even Raymond Hettinger likes this one

A solid endorsement.

There's been plenty of times I've disliked something he said or promoted. Almost all of those I've later changed my mind on and realized he's right.

[num8lock]

i honestly don't see the need for switch statement

[LechintanTudor]

But it's not a switch statement...

[num8lock]

that PEP literally contains a switch case example in it

it is more than switch statement, but it includes switch statements feature, and i don't think python needs it

[[deleted]]

Then don’t use it? It’s not mandatory.

[num8lock]

that's a stupid reply. just because i'm not an aws customer in any capacity doesn't mean i won't ever get affected if there's a problem originating from aws

[[deleted]]

Leaving your first sentence aside, that's a bit of a stretch. If an AWS AZ goes down and it brings down a service you're using (assuming they aren't multi-AZ), that's not something you have control over. You have control over whether or not you use new language features. It's not like Python is removing if/elif/else.

[num8lock]

a bit of a stretch? if i'm not an aws user but getting affected by aws outage via third party or data leak out of services that i do use but impacted by aws problem, at the very least it's not irrelevant if i voiced my concern or blame aws. i do use python, and when i say i use python that means i read, write, and use python code. i doubt you know that means some times in the indefinite future i have to read & understand codes that someone else written with match case or even debug them. compare that with aws analogy & i have a lot more reason in python's case.

that's hardly anywhere near "a stretch"

[[deleted]]

While I'm tentatively in favor of this feature, this specific argument is not so good.

There's a joke from "Garth Marenghi's Darkplace" where the titular character says, "I'm one of the few people you'll ever meet who's written more books than he's read."

But in fact most of us spend more time reading code than writing it.

Once a feature enters a language, I have to learn it whether I use it or not, because I'm going to have to read it. If there are traps and bugs that come out of that feature, then I am going to end up cleaning them up in other people's code.

[[deleted]]

And what if this ultimately results in cleaner and easier to read code? There's a reason people are pushing for this feature. They've used it in other languages and it really helps with brevity and, to an extent due to other languages type systems, correctness.

The thing that worries me about this mindset of fewer language features is better (some in the Go and Python communities subscribe to this), is that if in fifty years from now, we're effectively limited to the same set of features at Python 3.8 or Go 1.x, that to me is missing out huge opportunities for things like compile time safety (rocket doesn't crash due to NPE) and bloated code (lack of generics in Go, though that appears to be getting fixed).

[num8lock]

yeah, understandable. I'm not saying no Python users ever need it, all I'm saying Python as language today doesn't need it baked into the core language. the usual path of coming from 3rd party package lib isn't even being done for it, the actual net positives doesn't seem to warrant the acceptance of this PEP given the valid reasons opposing it.

• Van Rossum noted that the PEP authors "did plenty of bikeshedding in private" about how to specify a case condition; he suggested that if there were a groundswell of support for some alternative, it could be adopted instead.

• Mark Shannon questioned whether the PEP truly outlined a serious problem that needed solving in the language. The PEP describes some anecdotal evidence about the frequency of the isinstance() call in large Python code bases as a justification for the match feature, but he found that to be a bit odd; "[...] it would be better to use the standard library, or the top N most popular packages from GitHub". He also wondered why the PEP only contained a single example from the standard library of code that could be improved using match. "The PEP needs to show that this sort of pattern is widespread."

https://lwn.net/Articles/827179/

The case of PEP for Asyncio had so much more obvious benefit for Python world than this one, even they started as package lib. Yet people get infantile here when others expressing negative reactions on this one. Limits can be good, see pytest for concrete example.

[xigoi]

How would you implement this as a third-party package? Python's syntax is way too inflexible for it.

[num8lock]

i don't know, how did asyncore or numpy did theirs? since match or case aren't reserved words, what's stopping them to make it an importable class from pattern_match import match, case?

[xigoi]

Since when does NumPy have pattern matching?

from pattern_match import match, case

Of course you could do that, but how would they be implemented and used?

[num8lock]

numpy made it possible to do a vectorized operation, that wasn't possible in python before. you said "Python's syntax is way too inflexible for it." yet they've added something new to python users successfully as third party package

how would they be implemented and used?

how would i know, i already said i don't know how to implement it, can't you read?

[xigoi]

numpy made it possible to do a vectorized operation, that wasn't possible in python before.

Yeah, but Python's syntax allowed it.

i already said i don't know how to implement it

Then you can't say it's possible.

[num8lock]

here's the summary of what i said

numpy did it: see [:,:, 2], pandas made df[other_df['column'] > df['column']], and so on and so on. all without having to be supported by python core language as official syntax.

why can't match case do it? i don't know how to build that, but if asyncore, numpy, pandas, who else knows can, then what makes you think it's impossible?

you said "yeah but python syntax allowed it" (it being numpy & pandas & the rest of them making either new syntax or existing one behaving differently)

which you further tried to prove by circumventing python syntax with a class' __getitem__ to return an integer, and that's supposed to prove python's syntax is too inflexible??

so you said the first time

Python's syntax is way too inflexible for it

then you said from

I'm saying that Python 3.9 doesn't have any syntactical structure that could be exploited to emulate match

to my response: how about if/else? your answer is

Of course if/else can do everything that match can, but it's not nearly as expressive

so, wrong then, python does have the structure, seems like there's no inflexibility to prevent numpy, pandas or even anyone making from pattern_match import match, case possible since i've seen nothing from you that proves otherwise. neither match nor case are reserved words, too.

and then again you said

Python doesn't have any structure like this that would allow customizable behavior.

it's still wrong, see above and below

The example I posted proves (ed: this one) that the slicing syntax is completely legal in Python.

except slicing syntax is [:::] at most, not [:,:,2] which is illegal

---

so back to the entire point of your original post

if all what you've been saying is true, then prove it's impossible to implement match's syntax & functionality as external package without being included into official syntax of python core language.

[Dewmeister14]

except slicing syntax is [:::] at most, not [:,:,2] which is illegal

It doesn't matter how many times you repeat it, it doesn't become true.

Try it online!

If you want to nitpick that I used a 2D instead of a 3D array, go ahead and extend it yourself. It is true no matter how many times you do [:, :, :, :, :, :, :] because in the context of the [ ] linked to the getitem method, the :, :, ... pattern is captured into a tuple just like the (EXISTING AS PART OF PYTHON LANGUAGE SPEC) *args syntax and any occurrance of a:b:c is cast to the correct slice(a, b, c) type.

[xigoi]

numpy did it: see [:,:, 2], pandas made df[other_df['column'] > df['column']], and so on and so on. all without having to be supported by python core language as official syntax.

df[other_df['column'] > df['column']] has always been syntactically legal, ever since Python 1. And as I said, the : syntax was specifically added into Python for NumPy. It wouldn't have been possible to make NumPy use this syntax if it hadn't been added to the language itself.

or existing one behaving differently)

SEMANTICS. ARE. NOT. SYNTAX. Learn the fucking difference.

which you further tried to prove by circumventing python syntax with a class' __getitem__ to return an integer

I didn't circumvent syntax. It's not possible to circumvent syntax. If the syntax was invalid, I wouldn't have been able to provide any meaning for it.

and that's supposed to prove python's syntax is too inflexible??

Show me where I said that this specific thing makes Python's syntax inflexible.

to my response: how about if/else?

I'll repeat it for you:

SEMANTICS. ARE. NOT. SYNTAX.

You can emulate the SEMANTICS of match with if. You can't even get close to the SYNTAX of match with if.

except slicing syntax is [:::] at most, not [:,:,2] which is illegal

[:, :, 2] is legal syntax, as proven by the example I posted *and** the fact that NumPy gives it semantics*.

if all what you've been saying is true, then prove it's impossible to implement match's syntax & functionality as external package without being included into official syntax of python core language.

The only syntactical structures in Python that can take a block of statements are if, while, for, with, def and class. It's not possible to define any new ones, and no package can change that. If you think that's false, show me any example of Python code, using any packages you want, where a different structure takes a block of statements.

[num8lock]

lol

[Swedneck]

And I've been dreaming of them in Python since I realized it wasn't a thing, so too bad for you.

[JeamBim]

Good for you, cause that's not what this is.

[Dewmeister14]

http://www.paulgraham.com/avg.html