Does a class need to inherit from a typing.Protocol for a type checker to accept it?

## The claim `Protocol` makes `typing.Protocol` is Python's way of writing an interface that is satisfied by **shape** rather than by **declaration**. A protocol class body lists members -- methods, and data attributes as annotations -- and a static type checker treats any class whose own members are compatible with that list as an acceptable value wherever the protocol is annotated. The implementing class does not import the protocol, does not name it as a base class, and does not register itself anywhere. This is what "structural" means, in contrast with the *nominal* typing that most class hierarchies use, where a value is accepted because of what it inherits from. ```python from typing import Protocol class Renderer(Protocol): def render(self, doc: str) -> bytes: ... class PdfRenderer: # imports nothing, inherits nothing def render(self, doc: str) -> bytes: return doc.encode() def convert(renderer: Renderer, doc: str) -> int: return len(renderer.render(doc)) convert(PdfRenderer(), "report") # accepted by the checker ``` ## Who owns the interface The practical consequence is that the interface moves to the **consumer**. In a nominal design, the provider of a class must have anticipated your abstraction and inherited from it; if it did not, you are stuck writing an adapter. With a protocol, the function that needs `render` declares a one-method protocol next to itself, and every class that already has a compatible `render` -- yours, a colleague's, one from a package you cannot modify -- conforms retroactively and silently. The protocol can therefore be deliberately narrow: it should list the members the consumer actually calls, not everything a plausible implementation might offer. A one-method protocol is a normal and good protocol. ## What "matching" means Matching is more than matching names. The checker compares signatures: parameter kinds and names, defaults, and the return type must be compatible. A method whose parameter is annotated `str` in the protocol may be implemented with a wider parameter type (`object` or `str | bytes`) because parameters are contravariant, and may return a narrower type than declared because returns are covariant. Extra members on the implementing class are irrelevant -- structural conformance asks "does it have at least this?", never "does it have exactly this?". Missing members, mismatched arity, or an incompatible return type produce an error, and crucially that error is reported **at the use site**: the line that passes the object into the protocol-annotated parameter, which is often nowhere near the class definition. ## Runtime does nothing by default None of this is enforced when the program runs. Annotations are not checks; a class that does not conform is still passed happily and fails later with `AttributeError` or `TypeError` if the missing member is reached. `isinstance(x, Renderer)` against a plain protocol does not fall back to a structural test -- it raises, because instance checks require an opt-in decorator. Two runtime rules do bite at class-creation time, though. A protocol class cannot be instantiated: `Renderer()` raises `TypeError: Protocols cannot be instantiated`, because a protocol is a specification, not a thing. And a protocol may only inherit from other protocols; mixing a non-protocol base into a `Protocol` subclass raises `TypeError: Protocols can only inherit from other protocols`. The reverse is fine and often useful: a concrete class may list a protocol among its bases. ## Explicit subclassing as an option, not a requirement Naming the protocol as a base class -- `class PdfRenderer(Renderer):` -- is legal and changes two things. The checker verifies the implementation once, at the class definition, so a missing or misspelled method is reported there instead of at every call site; and the subclass inherits any member of the protocol that was given a real body, which serves as a default implementation. What it does *not* do is change who else conforms: unrelated classes with the right shape are still accepted, because the protocol has not stopped being structural. Note that a protocol member written as `...` is not abstract at runtime unless it is also decorated with `abc.abstractmethod`, so a subclass that forgets to implement it will instantiate happily and return `None` from that member -- the checker is what catches this, not the interpreter. ## When to reach for it Protocols pay off when the dependency you are describing is small and the implementations are many or outside your control: a callback shape, a "thing with `read`", a narrow port at a module boundary that you want to substitute in tests without inheriting anything. They cost you the ability to point at a single class as the definitive list of implementations, which is exactly the trade a structural interface makes.