PEP 634 - underscore wildcard, or a keyword?

PEPs
#1

I love the new pattern matching with match/case, and anticipate using it heavily. What I’m not so keen on is the “match everything else” at the end (case _).

Why couldn’t a hard, “final” case be added such as this:

match myval:
    case 1:
        return 'One'
    case 2:
        return 'Two'
    finally:
        return 'No value given'

I feel like this has two benefits:

  1. It matches other control flow that has a “final” case, such as if/elif/else and try/except/finally.
  2. It could enforce that there are no further conditions added after it, that will never be reached… with case _, it would be easy to add another case beneath that without thinking.

case _ could still work, but something like finally would be available and more accepted? maybe?

2 Likes
#2

“finally” implies that the clause will always be executed when the code
leaves the match statement, no matter which case branch was taken.

Just as in try…finally, the finally clause is always executed (if
anything is executed at all).

1 Like
#3

This is true, which means finally is not a good choice… default maybe? Whatever is most explicit.

1 Like
#4

I believe adding a new case after a wildcard match is a syntax error.

1 Like
#5

case _ is already close to as explicit as it is possible to get. It is
a case, and it is the wildcard case.

Changing that to “finally” or “default” or “else” or “otherwise” etc is
less explicit, because it is no longer explicity stating that this is a
case.

I think that, rather than “most explicit”, you are asking for wildcards
to use a word rather than a symbol. But symbols can be just as explicit
as words:

x + y

x plus y

are equally explicit. Also, we can be too explicit:

if the boolean expression given by cond or flag is True then execute the following block of Python code:
block

versus

if cond or flag:
block

I think that having a symbol for wildcards is explicit enough and
adding a new keyword doesn’t add enough value to be worth it.

1 Like
#6

Those who really want something different can just write case default: instead of case _: (as long as they’re not surprised when the subject is bound to default upon hitting that case). :wink:

3 Likes
#7

Actually else sounds like a great choice, because it would be analogous to for/else, while/else, and try/else, not to mention if/else. There’s plenty of precendent for it in Python (it won’t be surprising to any experienced Python users) and it’s already a language keyword. Writing case _: is like writing elif True: in my opinion.

1 Like
#8

Currently, all cases of where else is allowed in Python (if, for and try), else is always allowed. With your suggestion, there can be cases where else is not allowed (ie when there’s already a clause which matches all remaining cases, aka irrefutable case).

In addition, the other arguments are found here: PEP 622 -- Structural Pattern Matching | Python.org, and here: PEP 635 -- Structural Pattern Matching: Motivation and Rationale | Python.org

#9

Very good point, and thanks for the links. What I am suggesting is that else: itself be irrefutable, and since irrefutability is (by the definition in the PEP) determined at parse time, then the parser would treat it the same as it would treat any other situation that resulted in two irrefutable cases.

1 Like
#10

I just don’t find any of the 3 anti-else points to be especially compelling.

  1. It doesn’t have to be redundant if people use else instead of case_
  2. I don’t find it at all confusing to have else is at the same indent level as the other cases, since else is at the same level as, say, elif , representing separate conditions,
  3. What the PEP argues as “completionist” is what I argue as consistency. Where else in Python is the underscore character used in this sense?

I still say that else is far more explicit than case _. Ultimately I’m fine with case _, I just balk a bit when I see these sort of “weird” (that’s subjective I know) things showing up in Python, a language I’ve known to be remarkably consistent over the years.

1 Like