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.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.Let me add that the parser can easily deal with whatever we pick -- this is purely about human factors.
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.
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.