API design

Enables duck typing for objects that can be drawn, allowing functions to accept any drawable without requiring a common base class.

Game development: defining a common draw method for various renderable entities Graphics programming: allowing different shape classes to be rendered via a unified interface Plugin architecture: enabling third-party modules to provide drawable components

Python typing, game engines, GUI frameworks, scientific visualization

class protocol_name(Protocol): def method_name(self) -> return_type: pass

class ...(Protocol): def ...(self): ...

protocol_name: name of the protocol (PascalCase), method_name: name of the method (snake_case), return_type: return type annotation (e.g., None, str, int)

• typing.Protocol
• @runtime_checkable
• abstract base classes
• isinstance checks
• dependency injection

• Using abstract base classes (ABC) instead of Protocol for runtime enforcement (more verbose
• less flexible)
• using duck typing without protocols (lacks static type checking)

Forgot to import Protocol from typing: results in NameError; fix: add `from typing import Protocol` Using self incorrectly in method signature (e.g., missing self) causing TypeError when called; fix: include self as first parameter Confusing Protocol with ABC and expecting runtime isinstance checks to work by default; fix: either use @runtime_checkable decorator or rely on static type checking only Defining a method with a body other than pass (e.g., raising NotImplementedError) which is unnecessary for protocols; fix: keep body as pass or omit implementation Naming the protocol with lowercase or snake_case violating naming conventions; fix: use PascalCase for protocol names

Abstract Base Class (ABC): enforces interface at runtime via inheritance, whereas Protocol uses structural subtyping checked by static type tools Duck typing without protocols: relies solely on runtime attribute presence, lacking static type safety Zope interfaces: heavier-weight interface declaration with explicit declarations, less idiomatic in modern Python

Coming from Java: may expect interfaces to require inheritance and runtime isinstance checks — Python Protocol works structurally and is checked by static analyzers, not at runtime unless @runtime_checkable is used Coming from TypeScript: may assume structural typing works at runtime — Python's Protocol is primarily for static type checkers; runtime behavior requires explicit runtime_checkable decorator Coming from Go: may think interfaces require explicit implementation — Python Protocol is implicitly satisfied by any object with matching methods, no opt-in needed

• Protocol definition
• Structural typing
• Duck typing
• Interface segregation

Do not use Protocol when you need runtime enforcement of interface (e.g., for plugin discovery); use ABC or runtime_checkable decorator instead Performance impact is negligible as Protocol is erased at runtime; only static type checking overhead Protocol structural matching considers only method names and signatures, not attribute types unless annotated; be cautious with mutable default arguments in methods

Using Drawable protocol allows static type checkers to verify that functions receiving Drawable objects will have a callable draw method, preventing AttributeError bugs and enabling safe polymorphism across unrelated classes.

Think of a protocol as a contract written in Python: any class that signs it by implementing the draw method is accepted, no inheritance paperwork required.

Consider using @runtime_checkable from typing to enable isinstance checks with Protocol, or abstract base classes for richer runtime interface enforcement.