Yup, it's a conundrum. Note that we debated this in #2, though perhaps not enough (also note the very last comment there). It's also mentioned in the PEP under "Use a flat indentation scheme" in "Rejected Ideas".

The diff is actually a pretty strong argument.

Yes, I saw it was rejected, but I wanted to make sure we considered the above args before finally rejecting it :) I missed issue #2 's comments.

It does seem to be a matter of the following, and where the line is drawn:

Special cases aren't special enough to break the rules.
Although practicality beats purity.

My feeling is in practice, no one will really notice that the match statement doesn't quite follow the same indentation, because of its symmetry with if/elif/else and try/except. Then the two other args, especially the diff argument (a pragmatic reflection of symmetry) will follow.

We also see similar practice in the C code of Python, at least in ceval.c, which heavily uses switch/case. PEP 7 is silent on switch specifically, but it seems to otherwise encourage braces even when not mandatory and indentation after braces. But we do see examples like this in ceval.c:

        case TARGET(RAISE_VARARGS): {
            PyObject *cause = NULL, *exc = NULL;
            switch (oparg) {
            case 2:
                cause = POP(); /* cause */
                /* fall through */
            case 1:
                exc = POP(); /* exc */
                /* fall through */
            case 0:
                if (do_raise(tstate, exc, cause)) {
                    goto exception_unwind;
                }
                break;
            default:
                _PyErr_SetString(tstate, PyExc_SystemError,
                                 "bad RAISE_VARARGS oparg");
                break;
            }
            goto error;
        }

which in turn is part of an enormous switch. Arguing from C usage is likely a bit of a stretch, but certainly the above convention is a practicality argument.

I would argue in favor of the additional indentation (i.e. having case clauses be indented rather than at the same level as match), for two reasons:

1. Having a statement that ends with a colon, but no indented statement immediately below it, looks very wrong to me.

2. Overall I think the net effect of introducing match will be to shorten average line length rather than lengthening it. In the example code I have been writing, the extra 4 spaces of indentation are more than compensated by the succinctness of the code overall.

I concur with @viridia on this.

The diffs are certainly a good argument. However, only up to a certain point: the introduction of pattern matching is not primarily motivated by the need to simplify or rewrite the Python standard library. IMHO, the "Although practicality beats purity." aspect just does not seem to fully apply, because this refactoring is very short-lived and more or less a singular point in time.

Conceptually, the case clauses "belong" to the match block: they implicitly refer to the expression <expr> evaluated in match <expr>. In other words, the match-block keeps a hidden variable alive, which is removed once the match-block is left.

The suggestion to make the match-statement flat effectively means to remove the end-marker from the match-statement. Although the example in C seems to also be flat, the switch-statement still has a clear end-marker }. Python has a bit less leeway in this because the DEDENT is basically the only end-marker.

Finally, I also think the grammar is much more stable, particularly since case is a soft keyword. Consider a silly example like this:

match x:
case 1:
    ...
case 2:
    ...
case (3)   # <- is this still a case clause?

Is the case(3) here a valid function call or a case clause with the colon missing? Yes, the new parser can surely handle this, but I think it adds unnecessary complexity.

If case is a soft keyword, the parser has no choice but to treat that last line as a call to a function named case.

That's actually a good argument for indenting or for using as...

Personally in such cases if a small diff is really important I would resort to using a "half indent" for the newly-inserted case level. Yes, that's cheating, but PBP and such. :-)

Or ignore whitespace in the diff.

I am fairly skeptical that the 'half-indent' strategy for minimizing indentation levels would be widely adopted, for several reasons:

• It would difficult for editors that auto-indent to make an exception based on context. Remember, most editors aren't as smart as an auto-formatter, but are smart enough to indent and unindent.
• People who establish standards for coding style tend to be fairly pedantic in their tastes, and having an anomalous indentation level would seem inconsistent.

And honestly I don't think it's necessary.

I don't contest any of that. I'm just reporting what I have done in similar situations. :-)