Python's dynamic nature and support for duck typing have long been praised for their flexibility. However, as codebases grow larger and more complex, the benefits of static type checking become increasingly clear. But how can we reconcile the flexibility of duck typing with the safety of static type checking? Enter Python's Protocol class.
In this tutorial, you'll learn:
What duck typing is and how it's supported in Python
The pros and cons of duck typing
How Abstract Base Classes (ABCs) attempt to solve typing issues
How to use
Protocolto get the best of both worlds: duck typing flexibility with static type checking
Understanding Duck Typing
Duck typing is a programming concept where the type or class of an object is less important than the methods it defines. It's based on the idea that "If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck."
In Python, duck typing is fully supported. For example:
class Duck:
def quack(self):
print("Quack!")
class Person:
def quack(self):
print("I'm imitating a duck!")
def make_it_quack(thing): # Note: No type hint here
thing.quack()
duck = Duck()
person = Person()
make_it_quack(duck) # Output: Quack!
make_it_quack(person) # Output: I'm imitating a duck!
In this example, make_it_quack doesn't care about the type of thing. It only cares that thing has a quack method. Note that there's no type hint for the thing parameter, which is typical in duck-typed code but can lead to issues in larger codebases.
Pros and Cons of Duck Typing
Duck typing offers several advantages:
Flexibility: It allows for more flexible code that isn't tied to specific types.
Easier code reuse: You can use existing classes in new contexts without modification.
Emphasis on behavior: It focuses on what an object can do rather than what it is.
However, it also has some drawbacks:
Lack of clarity: It can be unclear what methods an object needs to implement.
Runtime errors: Type-related errors are only caught at runtime.
Less IDE support: IDEs struggle to provide accurate autocompletion and error checking.
The ABC Solution
One approach to addressing these issues is using Abstract Base Classes (ABCs). Here's an example:
from abc import ABC, abstractmethod
class Quacker(ABC):
@abstractmethod
def quack(self):
pass
class Duck(Quacker):
def quack(self):
print("Quack!")
class Person(Quacker):
def quack(self):
print("I'm imitating a duck!")
def make_it_quack(thing: Quacker):
thing.quack()
duck = Duck()
person = Person()
make_it_quack(duck)
make_it_quack(person)
While this approach provides better type checking and clearer interfaces, it has disadvantages:
It requires inheritance, which can lead to inflexible hierarchies.
It doesn't work with existing classes that you can't modify.
It goes against Python's "duck typing" philosophy.
Protocols: The Best of Both Worlds
Python 3.8 introduced the Protocol class, which allows us to define interfaces without requiring inheritance. Here's how we can use it:
from typing import Protocol
class Quacker(Protocol):
def quack(self):...
class Duck:
def quack(self):
print("Quack!")
class Person:
def quack(self):
print("I'm imitating a duck!")
def make_it_quack(thing: Quacker):
thing.quack()
duck = Duck()
person = Person()
make_it_quack(duck)
make_it_quack(person)
Let's break this down:
We define a
Quackerprotocol that specifies the interface we expect.Our
DuckandPersonclasses don't need to inherit from anything.We can use type hints with
make_it_quackto specify that it expects aQuacker.
This approach gives us several benefits:
Static type checking: IDEs and type checkers can catch errors before runtime.
No inheritance required: Existing classes work as long as they have the right methods.
Clear interfaces: The Protocol clearly defines what methods are expected.
Here's a more complex example showing how Protocols can be as complex as needed (Shape), keeping your domain classes (Circle, Rectangle) flat:
from typing import Protocol, List
class Drawable(Protocol):
def draw(self): ...
class Resizable(Protocol):
def resize(self, factor: float): ...
class Shape(Drawable, Resizable, Protocol):
pass
def process_shapes(shapes: List[Shape]):
for shape in shapes:
shape.draw()
shape.resize(2.0)
# Example usage
class Circle:
def draw(self):
print("Drawing a circle")
def resize(self, factor: float):
print(f"Resizing circle by factor {factor}")
class Rectangle:
def draw(self):
print("Drawing a rectangle")
def resize(self, factor: float):
print(f"Resizing rectangle by factor {factor}")
# This works with any class that has draw and resize methods,
# regardless of its actual type or inheritance
shapes: List[Shape] = [Circle(), Rectangle()]
process_shapes(shapes)
In this example, Circle and Rectangle don't inherit from Shape or any other class. They simply implement the required methods (draw and resize). The process_shapes function can work with any objects that have these methods, thanks to the Shape protocol.
Summary
Protocols in Python provide a powerful way to bring static typing to duck-typed code. They allow us to specify interfaces in the type system without requiring inheritance, maintaining the flexibility of duck typing while adding the benefits of static type checking,
By using Protocols, you can:
Define clear interfaces for your code
Get better IDE, (static type checking), support and catch errors earlier
Maintain the flexibility of duck typing
Leverage type checking for classes you are unable to modify.
If you want to learn more about Protocols and type hinting in Python, check out the official Python documentation on the typing module, or explore advanced static type checking tools like mypy.
Happy coding, and may your ducks always quack with type safety!
You can find more of my content, including my newsletter here