Pattern matching accepted for Python

Re:Pattern matching accepted for Python by hyperbovine on Wednesday February 10, 2021 @05:01AM (#26087359)

But all of these alternatives are strictly less intuitive than the original expression. A big reason why I got into Python was because it’s the language that can be “read by anyone”, even those who do not know Python. This latest PEP, coming on the heels of several others like it, shows how alarmingly far from the ideal we’ve come since 2.7.

[ Parent | on HN ]

Re:Pattern matching accepted for Python by chriswarbo on Wednesday February 10, 2021 @06:30AM (#26087910)

> But all of these alternatives are strictly less intuitive than the original expression.

I agree; I was just trying to show how pattern guards work. I would only resort to pattern guards if I need a `cond` (like my last example), or on a few cases of a more 'natural' pattern match, e.g.

    match foo():
      case OK(msg):
        return success(msg)
      case NotFound(_) if isQuery:
        return success("No results matched query")
      case NotFound(msg):
        return failure(msg)
      ...

If I were to implement your original example (i.e. 'which of these constants do I have?'), I'd probably still go with a "dictionary dispatch" (especially since it's an expression, so it works in lambdas, etc.):

    return {
      NOT_FOUND: default,
      OK: response,
    }[getCode()]()

[ Parent | on HN ]

Re:Pattern matching accepted for Python by pansa2 on Wednesday February 10, 2021 @05:29AM (#26087524)

> A big reason why I got into Python was because it’s the language that can be “read by anyone”, even those who do not know Python.

Yes! For the first 2 decades of its life, people loved Python because it was like “executable pseudocode”. Unfortunately over the last 5-10 years it seems to have given up on that idea, instead becoming more and more like “whitespace-sensitive C++”.

[ Parent | on HN ]