Quoting Koos Zevenhoven <k7hoven@gmail.com>:

> (1) Class pattern that does isinstance and nothing else.
>
> If I understand the proposed semantics correctly, `Class()` is equivalent to checking `isinstance(obj, Class)`, also when `__match_args__` is not present. However, if a future match protocol is allowed to override this behavior to mean something else, for example `Class() == obj`, then the plain isinstance checks won't work anymore! I do find `Class() == obj` to be a more intuitive and consistent meaning for `Class()` than plain `isinstance` is.
>
> Instead, the plain isinstance check would seem to be well described by a pattern like `Class(...)`. This would allow isinstance checks for any class, and there is even a workaround if you really want to refer to the Ellipsis object. This is also related to the following point.
>
> (2) The meaning of e.g. `Class(x=1, y=_)` versus `Class(x=1)`
>
> In the proposed semantics, cases like this are equivalent. I can see why that is desirable in many cases, although Class(x=1, ...)` would make it more clear. A possible improvement might be to add an optional element to  `__match_args__` that separates optional arguments from required ones (although "optional" is not the same as "don't care").

Please let me answer these two questions in reverse order, as I think it makes more sense to tackle the second one first.

**2. Attributes**

There actually is an important difference between `Class(x=1, y=_)` and `Class(x=1)` and it won't do to just write `Class(x=1,...)` instead.  The form `Class(x=1, y=_)` ensures that the object has an attribute `y`.  In a way, this is where the "duck typing" is coming in.

The class of an object and its actual shape (i.e. the set of attributes it has) are rather loosely coupled in Python: there is usually nothing in the class itself that specifies what attributes an object has (other than the good sense to add these attributes in `__init__`). 

Conceptually, it therefore makes sense to not only support `isinstance` but also `hasattr`/`getattr` as a means to specify the shape/structure of an object.

Let me give a very simple example from Python's `AST` module.  We know that compound statements have a field `body` (for the suite) and possibly even a field `orelse` (for the `else` part).  But there is no common superclass for compound statements.  Hence, although it is shared by several objects, you cannot detect this structure through `isinstance` alone.  By allowing you to explicitly specify attributes in patterns, you can still use pattern matching notwithstanding:
```
match node:
    case ast.stmt(body=suite, orelse=else_suite) if else_suite:
        # a statement with a non-empty else-part
        ...
    case ast.stmt(body=suite):
        # a compound statement without else-part
        ...
    case ast.stmt():
        # a simple statement
        ...
```

The very basic form of class patterns could be described as `C(a_1=P_1, a_2=P_2, ...)`, where `C` is a class to be checked through `isinstance`, and the `a_i` are attribute names to be extracted by means of `getattr` to then be matched against the subpatterns `P_i`.  In short: you specify the structure not only by class, but also by its actual structure in form of required attributes.

Particularly for very simple objects, it becomes annoying to specify the attribute names each time.  Take, for instance, the `Num`-expression from the AST.  It has just a single field `n` to hold the actual number.  But the AST objects also contain an attribute `_fields = ('n',)` that not only lists the *relevant* attributes, but also specifies an order.  It thus makes sense to introduce a convention that in `Num(x)` without argument name, the `x` corresponds to the first field `n`.  Likewise, you write `UnarOp('+', item)` without the attribute names because `_fields=('op', 'operand')` already tells you what attributes are meant.  That is essentially the principle we adopted through introduction of `__match_args__`.

**1. Match Protocol**

I am not entirely sure what you mean by `C() == obj`.  In most cases you could not actually create an instance of `C` without some meaningful arguments for the constructor.

The idea of the match-protocol is very similar to how you can already override the behaviour of `isinstance`.  It is not meant to completely change the semantics of what is already there, but to allow you to customise it (in some exciting ways ^_^).  Of course, as with everything customisable, you could go off and do something funny with it, but if it then breaks, that's quite on you.

On the caveat that this is **not part of this PEP (!)**, let me try and explain why we would consider a match protocol in the first place.  The standard example to consider are complex numbers.