On 11/07/2020 19:29, Jim J. Jewett wrote:

To me, "else:" has a slightly different meaning than "case _:" case _: essentially a default, ensuring that the match logic is complete. else: OK, the subject of this match failed, here is our fallback logic. Whether this distinction is important enough to express in code is another question, as is whether or not anyone but me would follow this "obvious" convention. So I'm not convinced the difference justifies the existence a second syntax. But I'm also not sure it doesn't, particularly if that distinction were given in the PEP and in documentation for the match statement. -jJ

Could you construct two examples to prove behaviour would be different between the two? To me the two meanings seem too similar to make a difference in code.

On 12/07/2020 00:31, Guido van Rossum wrote:

Hm... Just the fact that people have been arguing both sides so convincingly makes me worry that something bigger is amiss. I think we're either better off without `else` (since the indentation of `case _` cannot be disputed :-), or we have to revisit the reasons for indenting `case` relative to `match`. As MRAB said, it's a case of picking the least inelegant one.

Let me add that the parser can easily deal with whatever we pick -- this is purely about human factors.

That is a good point. I don't think there would be any particular objection to allowing one case to catch anything that wasn't caught before—the issue is with making _ (or any other particular symbol) special for the occasion, or at the very least none of those proposed thus far has been universally accepted.

Was anything beside _ and ... proposed? What if case object(): or case any: did that instead? The former is already used to a similar meaning in the context of a match block, the latter would be very obvious to any reader and, since it's already a builtin, few would think shadowing it for use as a store-identifier would be a good idea.

On 11/07/2020 21:13, Eric Nieuwland wrote:

This could also resolve the discussion on indentation of the ‘case’ parts and the placement of the default matching: match <expression> [as <var>]: <preparation statements> case <pattern> [<guard>]: <statements> … [else: <statements>] within the preparation statements it would then be allowed to use undefined variables as receivers of matched parts.

This is intriguing, but I do share Greg Ewing's doubt: what happens if you need no preparation? Personally I'd accept if the line could be omitted altogether, but I understand many others are opposed to having the line following a colon be indented at the same level, and likewise I don't think the idea of having to write pass (or ...) explicitly when no preparation is needed will be well received.