What is a Protocol in the typing module, and how does it enable structural typing ("duck typing" with static checks)?
Protocol defines a structural interface: any class with matching methods is compatible, no inheritance required
A Protocol from typing describes a set of methods and attributes that a type must provide. Unlike an abstract base class, a class does not need to inherit from the Protocol to be considered compatible. A static type checker will accept any class that structurally matches the Protocol, which brings duck typing into the static type system. This is called structural typing. For example, if you define a Protocol with a close() method, any object with close() satisfies it, whether or not it subclasses the Protocol. You can also use @runtime_checkable to allow isinstance checks against the Protocol at runtime, but that only checks method presence, not signatures. Protocols are ideal for defining interfaces for dependency injection, plugin systems, and callbacks without forcing inheritance. The trade-off is that errors can be less obvious: a missing method is caught by the type checker, not at runtime, unless you use runtime_checkable.
- 1
Protocol classes are defined with class MyProto(Protocol): ... and list the required methods and attributes.
- 2
A class satisfies the Protocol if it has all the required members with compatible types. No explicit inheritance is needed.
- 3
@runtime_checkable allows isinstance and issubclass checks, but only verifies method names, not signatures or types.
- 4
Protocols can be generic and can inherit from other Protocols.
- 5
Trade-off: structural typing is flexible and decoupled, but it can be harder to discover all implementers. Nominal typing (ABCs) is more explicit.
- 6
Common mistake: expecting runtime enforcement from a Protocol. It only enforces at type-check time unless runtime_checkable is used, and even then only superficially.
- 7
Common mistake: putting implementation code in a Protocol. It should only declare the interface.
- 8
Version note: Protocol was introduced in Python 3.8 via typing.Protocol (PEP 544). It is also available in typing_extensions for older versions.
Scenario Questions
0-2 years experience
- 1Do you need to inherit from a Protocol to satisfy it?
- 2What does @runtime_checkable allow you to do?
2-5 years experience
- 1You have three classes that all have a read() method but no common base. How do you type-annotate a function that accepts any of them?
- 2You want to check at runtime whether an object satisfies a Protocol. What are the caveats?
5-8 years experience
- 1You are designing a plugin system. Would you use Protocol or ABC? Why?
- 2You need a Protocol with a generic method. How do you define it?
8+ years experience
- 1Design a library API that uses Protocols to allow users to plug in their own implementations without inheriting from your classes, and explain how you document and test the contract.
- 2Compare Protocol, ABC, and duck typing with no annotations on maintainability, type safety, and runtime behavior in a large codebase.
Follow-up Questions
- How does Protocol differ from an abstract base class?
- What are the limitations of @runtime_checkable?