Top-level syntax about patma

[Tobias-Kohn]

Agreed. The PEP already demonstrates quite extensively that we considered a range of variants. I just wanted to make sure we have thought of this variant in case, as you say, someone brings it up later on during the discussion.

[brandtbucher]

A slight variant that saves a line and a level of indentation.

match <expression> case <pattern> [if <expression>]: <block>
case <pattern> [if <expression>]: <block>
# repeated cases

+0, personally. It's not ugly to me, but I'm sure others have opinions about the first pattern not lining up.

[gvanrossum]

Can't say I like the first pattern hiding behind the match clause.

Some other variants that have been proposed:

• Don't indent the cases. The downside is that it would probably trip up most auto-indent implementations in IDEs:

match <expression>:
case <pattern> [if <expression>]: <block>
...

• Swap match and case keywords (really! e.g. Coconut):

case <expression>:
    match <pattern> [if <expression>]: <block>
    ...

• No case keyword (could be combined with other variants too, e.g. case or no-indent):

match <expression>:
    <pattern> [if <expression>]: <block>
    ...

• Other keywords, e.g.

from <expression>:
    in <pattern> [if <expression>]: <block>

See #3 about whether to have guards (I think we should).

[gvanrossum]

See also #27 -- the only seriously remaining open issue ('as' vs. 'case').

[Tobias-Kohn]

Just to be complete here, there is one more variant we haven't considered so far:

match:
    <expression>
case <pattern>:
    <block>
case <pattern>:
    <block>

This would be very similar to how try/except/finally currently works (syntactically).

At first glance, this looks like ticking all the boxes. It saves that level of indentation, and it even has a similar structure to something that already exists in Python. However, there is one isse with this which I find quite significant: the <expression> above would look like a statement. Or, put differently: this would introduce a first case of where (parts of) Python would be treated as an expression-oriented language, rather than a statement-oriented one. In my view, this rather disqualifies this proposal and feels much more "unpythonic" than what we are doing now.

[gvanrossum]

@Tobias-Kohn I agree with your argument against that variant. I believe I've seen it proposed before (maybe in your 2018 summary or blog post?). I don't think it's worth mentioning in the PEP unless someone on python-dev brings it up.