Ivan Levkivskyi

> Our API for `__match__` is entirely different It is actually not that different. The general logic is like this: interpreter asks an object: "Can you represent/unpack yourself as something...

Forgot about one thing: moving `isinstance()` to the `__match__` is definitely a very good idea, +1 on this. About other things: * I don't have strong attachment to coinciding names,...

One more deviation you forgot, what to do in case if all patterns fail? I propose to raise an exception. The main motivation is that most cases I have seen...

> This is just like for regular calls -- you can leave arguments off the end (assuming they have default values) Yes, but what if all three arguments are required?...

> Allowing multiple `as` clauses without intervening blocks feels like a syntax error OK, let's drop it. It is not really needed if we have `|`. > we can specify...

> Perhaps rename to `__match_args_required__` so they all sort together? :+1: > Probably you meant "there are no precedents"? Oops, sorry, yes that was a bad typo :-)

> Also, let me propose that the marking would be a leading `.` I really like this idea. I was lately thinking that requiring pattern to be dotted to be...

@Tobias-Kohn some of your comments are in a sense outdated, because Guido already convinced me. The updated version (that I propose to take as a starting point) is in PR...

> Should it allow an `else` clause? I am not sure about this. On one hand a user would be surprised if it is not allowed, on the other hand...

A curious observation in favour of raising by default + one-off matches: out of six examples in `EXAMPLES.md` three examples have `raise` statement in the `else` part, one probably should...