Bring 'else' back?

[gvanrossum]

There were several commenters on today's revealing of the PEP on python-dev who want an else clause instead of case _: to enter final catch-all block. It's not terrible. If we do this I propose it should be indented with the case clauses:

match t:
    case P1():
        ...
    case P2():
        ...
    else:
        ...

I'm trying to hold this off a little longer, but it may be an easy thing to give.

[brandtbucher]

I can see the arguments for else, but for me it personally comes down to "preferably only one way to do it".

case _ is already a more flexible way to do it: unlike else, it can be guarded and reordered. It feels wrong to add the less powerful, duplicate else simply for completeness' sake.

Also, lets not forget that disallowing else is a two-way door.

[brandtbucher]

Also, ambiguity about the "correct" indentation level for else is another big strike against it, in my opinion.

[0312birdzhang]

I prefer default like Java,C++,JavaScript and Php.

[Delta456]

else is better for semantics. default is more for switch.

[Tobias-Kohn]

@0312birdzhang: I think at this point we should strive for a discussion on arguments rather than personal preferences, so as to effectively move forward with this.

First, I agree with @Delta456 in that default belongs into a switch-statement, which is not really what we are proposing here. Second, the two proposals on the table (else vs. case _) both extend existing syntax (in the case of case _ syntax that would come into existence because of the PEP, of course), whereas default is something else entirely without any connection to the rest of the proposal.

[Delta456]

If we really want case _ then the behavior of _ should be like Go's. If it cannot be like that then else is better suited.

[Tobias-Kohn]

I totally agree with @brandtbucher and feel he summarised the main arguments quite neatly.

The only argument I can see that really is in favour of else is that basically everything in Python also has an else clause (but, to be perfectly honest, this is something I really dislike as there is IMHO no natural or obvious way to connect a for-loop, say, with an else—but that's a different discussion that has taken place long ago). Hence, it might feel strange for experienced Python programmers not to have an else here.

If we were to bring else back than I am still convinced it would have to attach to match and not the case, i.e.:

match t:
    case P1():
        ...
else:
    ...

I see another argument in favour of case _:, though. Basically, we cannot outlaw case _: in a sensible way. After all, I could just write case x: and not use the value assigned to x, or case x | [x]:, etc. In other words: we are going to have case _: any way. This means that the discussion is actually about whether we want to allow else too, rather than instead of.

I am wondering whether the idea of having an else might be connected to the question of whether to raise if a value does not match any pattern... (issue #5)

[Tobias-Kohn]

@Delta456 Could you briefly explain what you mean by behaviour like Go's? Not everyone here is familiar with Go.

[Delta456]

See this

[viridia]

What specific aspect of Go's behavior are you referring to?

Given that the underscore is already a valid name in Python, and there is an established convention of using it for values we want to ignore (such as in tuple unpacking), we can't radically alter the definition of it without breaking a lot of programs.

[Delta456]

I am refering that _ cannot be used anywhere in the program. If it does then it will raise an error.

I know that so I think we should go with else.

[elimisteve]

As @Delta456 alluded to, _ is a valid identifier in Python. This seems to bring ambiguity to the semantics of case _ when _ is a defined, in-scope variable. This is not uncommon and is even the recommended way to implement internationalization support in Django and elsewhere:

from django.utils.translation import ugettext as _

else is quite clear semantically but agree that the ambiguity of indentation level being unfortunate.

Right now my vote is for else, with default as a reasonable alternative.

[gvanrossum]

@Delta456 and @elimisteve, ‘_’ is used as a wildcard in the rest of the pattern matching syntax, ‘case _’ is just a special use of that. Read the README.md in this repo.

[Tobias-Kohn]

It seems like the discussion here is more and more circling about a different issue. Instead of discussing case _ vs. else, it is more about the semantics of _ and whether it should be a wildcard/throwaway (e.g., cf. issue #73).

The issue at hand is much rather whether we want/need an else, given that the pattern matching itself already supports a catch-all case. Depending on the micro-syntax of choice, the latter might then be written as case _:, case x:, case ...:, case *:, case:, or whatever.

I see no reason, however, to bring in default as an alternative here! We already have two perfectly good alternatives, which would both naturally extend what we already have. We are not, however, looking for yet another alternative out of the blue and with no precedent in either this PEP or Python. In the end, default would just introduce yet another keyword for a case that is already covered otherwise.