Protocol is the static type for 'has these methods', the way Python developers always meant duck typing. Circle and Rect are not subclasses of SupportsArea, but the type checker treats them as compatible because they have an area() method with the matching signature. There is zero runtime cost: the protocol exists only for the type checker. Use protocols for plugin interfaces, anything you want to accept user-defined classes for, or any function that previously documented its expectations in a docstring like 'must have a .read() method'.

Plain Protocols exist only at type-check time; isinstance(x, MyProtocol) raises a TypeError. Decorating with @runtime_checkable makes isinstance work by checking attribute presence at runtime. The check is shallow: it only verifies the attribute exists, not its full signature, so isinstance(obj, HasClose) returns True for any object that happens to have a .close attribute (even a non-callable one). Use it for the 'do you support this duck behaviour?' branch in plugin loaders or context managers, but pair it with explicit calls so signature mismatches still fail loudly.

Pick Protocol when you want to type-check existing classes you do not own (third-party libraries, user plugins, mock objects in tests). Pick an abstract base class when you want to ship default method implementations alongside the abstract requirements, or when 'is-a' relationships matter for isinstance and registry lookups. The two are not mutually exclusive: it is common to declare a Protocol for the public contract and a separate ABC that implements it for users who want the convenience helpers. The mental shortcut: ABC asks 'are you my subclass?', Protocol asks 'do you have my methods?'.