Python’s structural subtyping with Protocols is a game-changer for developers like me who love the language’s flexibility but want more safety. It’s a feature that lets us have our cake and eat it too - we get the best of both dynamic and static typing worlds.
I remember the first time I encountered Protocols. I was working on a large project where type inconsistencies were causing subtle bugs. I needed a way to ensure type safety without sacrificing Python’s duck typing philosophy. That’s when I stumbled upon Protocols, and it was like finding a hidden treasure in Python’s vast ecosystem.
Protocols allow us to define interfaces implicitly. Instead of focusing on what an object is, we concentrate on what it can do. This approach aligns perfectly with Python’s “duck typing” principle - if it walks like a duck and quacks like a duck, it’s a duck.
Let me show you a simple example:
from typing import Protocol
class Drawable(Protocol):
def draw(self) -> None:
...
def render(item: Drawable):
item.draw()
class Circle:
def draw(self):
print("Drawing a circle")
class Square:
def draw(self):
print("Drawing a square")
render(Circle()) # This works
render(Square()) # This also works
In this example, Drawable is a Protocol that defines a draw method. Any class that implements a draw method is considered a Drawable, regardless of its actual type. This is structural subtyping in action.
One of the coolest things about Protocols is that they’re checked at runtime. This means we can use isinstance() to check if an object implements a Protocol:
from typing import runtime_checkable
@runtime_checkable
class Quackable(Protocol):
def quack(self) -> str:
...
class Duck:
def quack(self):
return "Quack!"
class Person:
def speak(self):
return "Hello!"
print(isinstance(Duck(), Quackable)) # True
print(isinstance(Person(), Quackable)) # False
This runtime checking is super useful when we’re dealing with dynamic code or when we’re not sure about the types we’re receiving.
Protocols aren’t just a neat trick - they’re a powerful tool for creating more maintainable and less coupled code. They allow us to define interfaces without creating explicit inheritance hierarchies. This can lead to more flexible and reusable code.
For instance, let’s say we’re building a data processing pipeline. We might have different types of data sources and data sinks. Instead of creating a complex inheritance hierarchy, we can use Protocols:
from typing import Protocol, List
class DataSource(Protocol):
def read(self) -> List[str]:
...
class DataSink(Protocol):
def write(self, data: List[str]) -> None:
...
def process_data(source: DataSource, sink: DataSink):
data = source.read()
# Do some processing here
sink.write(data)
class FileSource:
def read(self):
return ["line1", "line2", "line3"]
class DatabaseSink:
def write(self, data):
print(f"Writing {len(data)} lines to database")
process_data(FileSource(), DatabaseSink())
In this example, DataSource and DataSink are Protocols. Any class that implements the required methods can be used as a source or sink, regardless of its actual type. This makes our process_data function incredibly flexible and reusable.
Protocols shine when we’re working with third-party libraries or when we want to create plugins for our applications. We can define a Protocol that represents the interface we expect, and any object that matches that interface can be used, even if it wasn’t explicitly designed to work with our code.
One thing I love about Protocols is how they encourage us to think about interfaces and behaviors rather than concrete types. This often leads to more modular and composable code. It’s a subtle shift in thinking, but it can have a big impact on how we design our systems.
Protocols also play nicely with Python’s type hinting system. We can use them in function signatures, variable annotations, and even as generic parameters. This gives us the benefits of static typing while maintaining Python’s dynamic nature.
For example, we can create generic functions that work with any type that implements a certain Protocol:
from typing import TypeVar, Protocol, List
T = TypeVar('T', bound='Comparable')
class Comparable(Protocol):
def __lt__(self, other: 'Comparable') -> bool:
...
def sort(items: List[T]) -> List[T]:
return sorted(items)
class Person:
def __init__(self, name: str, age: int):
self.name = name
self.age = age
def __lt__(self, other: 'Person') -> bool:
return self.age < other.age
people = [Person("Alice", 30), Person("Bob", 25), Person("Charlie", 35)]
sorted_people = sort(people)
In this example, our sort function works with any list of items that implement the Comparable Protocol. The Person class implements __lt__, so it satisfies the Protocol and can be sorted.
One question that often comes up is how Protocols compare to abstract base classes (ABCs). While both can be used to define interfaces, Protocols have some distinct advantages. They’re more flexible, as a class doesn’t need to explicitly inherit from a Protocol to be considered compatible. They also align better with Python’s duck typing philosophy.
That said, ABCs still have their place. They’re useful when you want to provide default implementations for some methods, or when you need to use isinstance() checks in Python versions before 3.8 (which is when runtime-checkable Protocols were introduced).
As I’ve used Protocols more and more in my projects, I’ve found that they encourage me to write more modular and decoupled code. Instead of creating large, complex class hierarchies, I tend to define smaller, more focused Protocols. This often leads to code that’s easier to understand, test, and maintain.
One pattern I’ve found particularly useful is combining Protocols with composition. Instead of creating deep inheritance hierarchies, I define Protocols for different behaviors and then compose objects that implement these Protocols. This gives me a lot of flexibility in how I structure my code.
For example, let’s say we’re building a game with different types of characters:
from typing import Protocol
class Moveable(Protocol):
def move(self, x: int, y: int) -> None:
...
class Attackable(Protocol):
def attack(self, target: 'Attackable') -> None:
...
class Healable(Protocol):
def heal(self, amount: int) -> None:
...
class Player:
def __init__(self, name: str):
self.name = name
self.x = 0
self.y = 0
self.health = 100
def move(self, x: int, y: int) -> None:
self.x += x
self.y += y
print(f"{self.name} moved to ({self.x}, {self.y})")
def attack(self, target: 'Attackable') -> None:
print(f"{self.name} attacks {target.name}")
def heal(self, amount: int) -> None:
self.health += amount
print(f"{self.name} healed for {amount}. New health: {self.health}")
class Monster:
def __init__(self, name: str):
self.name = name
def attack(self, target: 'Attackable') -> None:
print(f"{self.name} attacks {target.name}")
def move_character(character: Moveable, x: int, y: int):
character.move(x, y)
def battle(attacker: Attackable, defender: Attackable):
attacker.attack(defender)
def heal_character(character: Healable, amount: int):
character.heal(amount)
player = Player("Hero")
monster = Monster("Goblin")
move_character(player, 10, 5)
battle(player, monster)
battle(monster, player)
heal_character(player, 20)
In this example, we define Protocols for different behaviors (Moveable, Attackable, Healable). Our Player class implements all of these, while the Monster class only implements Attackable. We can then write functions that work with any object that implements the relevant Protocol.
This approach gives us a lot of flexibility. We can easily add new types of characters that implement some or all of these behaviors, without needing to fit them into a rigid class hierarchy.
Protocols are particularly useful when working with external libraries or APIs. We can define Protocols that match the interface we expect, even if the library doesn’t use Protocols itself. This allows us to get the benefits of static typing with libraries that weren’t designed with type hints in mind.
For example, let’s say we’re working with a data processing library that expects objects with certain methods:
from typing import Protocol, List
import some_data_library
class DataProcessor(Protocol):
def process(self, data: List[str]) -> List[str]:
...
def run_processing(processor: DataProcessor, data: List[str]) -> List[str]:
return processor.process(data)
class MyCustomProcessor:
def process(self, data: List[str]) -> List[str]:
return [item.upper() for item in data]
# This works even if some_data_library.StandardProcessor doesn't explicitly implement DataProcessor
result = run_processing(some_data_library.StandardProcessor(), ["a", "b", "c"])
result = run_processing(MyCustomProcessor(), ["d", "e", "f"])
In this example, we define a DataProcessor Protocol that matches the interface we expect. We can then use this Protocol with both the library’s built-in processor and our custom processor, getting the benefits of type checking for both.
As I’ve used Protocols more, I’ve found that they encourage me to think more carefully about the interfaces in my code. Instead of focusing on concrete implementations, I think about the behaviors and capabilities that different parts of my system need. This often leads to more flexible and extensible designs.
Protocols have become an essential tool in my Python toolbox. They allow me to write code that’s both flexible and type-safe, bridging the gap between Python’s dynamic nature and the benefits of static typing. Whether I’m working on a small script or a large-scale application, Protocols help me write cleaner, more maintainable code.
If you haven’t explored Protocols yet, I encourage you to give them a try. They might just change the way you think about types and interfaces in Python. Happy coding!
