Python Polymorphism

Polymorphism, the ability for objects of different types to be used through a common interface, is a cornerstone of flexible and maintainable code. In Python, this concept is not enforced by a rigid type system but empowered by a dynamic, behavior-first philosophy. Mastering polymorphism allows you to build systems where components are interchangeable, your code is more reusable, and complex data workflows become elegantly simple. This is especially critical in data science, where you must seamlessly process data from diverse sources and formats through unified pipelines.

Duck Typing: Behavior Over Type

The most fundamental form of polymorphism in Python is duck typing. This principle states that an object's suitability for a task is determined by its behavior (the methods and attributes it has), not its explicit class or type. The name comes from the adage, "If it walks like a duck and quacks like a duck, then it must be a duck."

In practice, this means your functions should operate on "things that can do X," not "things of type Y." For example, a data processing function shouldn't demand a pandas.DataFrame. Instead, it should require an object that has a .to_csv() method. This design instantly makes your function compatible with pandas.DataFrame, polars.DataFrame, or any custom class you create that implements that method.

def export_data(data_object, filename):
    """Exports any object that has a .to_csv method."""
    data_object.to_csv(filename)

# This works with pandas DataFrame
import pandas as pd
df = pd.DataFrame({'A': [1, 2, 3]})
export_data(df, 'data.csv')

# It would also work with this custom class
class MyDataContainer:
    def __init__(self, data):
        self.data = data
    def to_csv(self, filename):
        # Custom export logic
        print(f"Exporting {self.data} to {filename}")

my_data = MyDataContainer([1,2,3])
export_data(my_data, 'myfile.csv')

Duck typing is the foundation of Python's flexibility. It allows libraries like NumPy and pandas to work together seamlessly; many functions accept any "array-like" object, whether it's a Python list, a NumPy ndarray, or a pandas Series.

Polymorphism Through Inheritance and Method Overriding

While duck typing is implicit, inheritance provides a more explicit, hierarchical structure for polymorphism. When a child class inherits from a parent, it can override parent methods to provide specific implementations. Code written to work with the parent class can then work with any child class, with each executing its own version of the method.

Consider a data validation system for different data types. A base class defines a common interface (validate()), and subclasses implement the specific logic.

class DataValidator:
    def validate(self, data):
        """Base validation method."""
        raise NotImplementedError("Subclasses must implement this.")

class NumericValidator(DataValidator):
    def validate(self, data):
        return isinstance(data, (int, float))

class StringValidator(DataValidator):
    def validate(self, data):
        return isinstance(data, str) and len(data) > 0

# Polymorphic function
def run_validation(validator: DataValidator, dataset):
    results = [validator.validate(item) for item in dataset]
    return all(results)

# Usage
num_validator = NumericValidator()
string_validator = StringValidator()

print(run_validation(num_validator, [1, 2.5, 3]))  # True
print(run_validation(string_validator, ["a", "b", ""]))  # False

The run_validation function is polymorphic; it operates on the DataValidator interface, unaware of the specific subclass (NumericValidator or StringValidator). This makes it trivial to add a new DateValidator or EmailValidator without changing the core pipeline logic.

Enforcing Interfaces with Abstract Methods

A potential issue with simple inheritance is that a subclass might forget to implement a crucial method. Abstract methods solve this by forcing subclasses to provide concrete implementations. In Python, you use the abc (Abstract Base Class) module to define a class with one or more abstract methods. You cannot instantiate an abstract class directly.

This is vital for designing robust plugin architectures or data source connectors where a missing method would cause a runtime failure later.

from abc import ABC, abstractmethod

class DataSource(ABC):
    """Abstract base class defining a data source interface."""
    
    @abstractmethod
    def connect(self):
        pass
    
    @abstractmethod
    def fetch_data(self, query):
        pass
    
    @abstractmethod
    def close(self):
        pass

class DatabaseSource(DataSource):
    def connect(self):
        print("Connecting to database...")
    
    def fetch_data(self, query):
        return f"Results for: {query}"
    
    def close(self):
        print("Closing database connection.")

class APISource(DataSource):
    def connect(self):
        print("Authenticating with API...")
    
    def fetch_data(self, query):
        return f"JSON response for: {query}"
    
    def close(self):
        print("Ending API session.")

# This pipeline works with any concrete DataSource
def run_etl_pipeline(source: DataSource, query):
    source.connect()
    data = source.fetch_data(query)
    print(f"Processing: {data}")
    source.close()

# Usage
db_source = DatabaseSource()
api_source = APISource()

run_etl_pipeline(db_source, "SELECT * FROM users")
run_etl_pipeline(api_source, "/users/endpoint")

Attempting to create a subclass of DataSource that doesn't implement all @abstractmethod decorators will result in a TypeError at instantiation, catching the error early.

Protocol-Based Polymorphism for Flexible Design

Python's protocols (formalized in Python 3.8+ with typing.Protocol) offer a modern, flexible alternative to inheritance for defining interfaces. A protocol specifies a set of methods or attributes a class must have (its structure) without requiring a class hierarchy. This is often called structural subtyping and is a formalization of duck typing that can be checked by static type checkers like mypy.

This is exceptionally useful in data science for creating functions that work with any object that has a certain shape, like a .fit() and .predict() method, regardless of whether it's from scikit-learn, statsmodels, or a custom model.

from typing import Protocol, TypeVar
import numpy as np

T = TypeVar('T', contravariant=True)

class MLModel(Protocol[T]):
    """Protocol for any machine learning model."""
    def fit(self, X: np.ndarray, y: np.ndarray) -> None: ...
    def predict(self, X: np.ndarray) -> np.ndarray: ...

def train_and_evaluate(model: MLModel, X_train, y_train, X_test):
    """Works with any object adhering to the MLModel protocol."""
    model.fit(X_train, y_train)
    predictions = model.predict(X_test)
    return predictions

# A scikit-learn model adheres to the protocol.
from sklearn.linear_model import LinearRegression
lr_model = LinearRegression()

# A custom model also works if it has .fit() and .predict().
class SimpleRegressor:
    def fit(self, X, y):
        self.coef_ = np.linalg.lstsq(X, y, rcond=None)[0]
    def predict(self, X):
        return X @ self.coef_

custom_model = SimpleRegressor()

# Both can be passed to the polymorphic function.
# train_and_evaluate(lr_model, X_train, y_train, X_test)
# train_and_evaluate(custom_model, X_train, y_train, X_test)

Protocols decouple interface definition from implementation, promoting extremely loose coupling. Your data pipeline doesn't depend on import sklearn; it depends on the MLModel structure.

Applying Polymorphism: Pipelines and Plugin Architectures

The true power of polymorphism is realized in application architecture. Two prime examples are data processing pipelines and plugin systems.

A polymorphic data processing pipeline can apply a series of transformations (clean, filter, transform) to data. Each step is defined by an interface (e.g., a DataTransform protocol with an apply() method). You can then create concrete classes like NormalizeTransform, EncodeCategoricalTransform, and ImputeMissingTransform. The pipeline loops through a list of these transform objects, calling .apply() on each, completely agnostic to the specific operation.

A plugin architecture leverages polymorphism to allow extending an application's functionality without modifying its core. The core application defines an abstract Plugin class with a run() method. Third-party developers create plugins (e.g., CSVLoaderPlugin, ChartGeneratorPlugin) that inherit from Plugin. The application dynamically discovers and loads these plugins, calling plugin.run() without needing to know the details. This pattern is ubiquitous in tools like data visualization libraries and text editors.

Common Pitfalls

1. Inheritance Overuse for "Is-A" Relationships: Don't use inheritance just to reuse code. If the relationship isn't truly a hierarchical "is-a" relationship (e.g., AdminUser is a User), favor composition and protocols. Forcing a square peg into a round inheritance hierarchy leads to fragile code.

• Correction: Use protocol-based polymorphism or duck typing. Have classes implement the required methods, and relate them through shared behavior, not shared ancestry.

1. Violating the Liskov Substitution Principle (LSP): This principle states that a subclass should be substitutable for its parent class without breaking the program. A common violation is a subclass overriding a method to do something entirely different or to add restrictive preconditions.

• Correction: Ensure overridden methods extend or specialize the parent's behavior, not replace its contract. The subclass method should accept at least the same parameters and fulfill the same post-conditions.

1. Ignoring Error Handling in Duck Typing: Duck typing can lead to AttributeError at runtime if an object doesn't have the expected method.

• Correction: Use defensive programming with hasattr() or try/except blocks when you cannot guarantee an object's type, or use isinstance() with a protocol for static type safety. Documentation is also key—clearly state the expected interface.

1. Creating "God" Abstract Base Classes: Defining an ABC with too many abstract methods forces implementers to write stubs for irrelevant methods, violating the Interface Segregation Principle.

• Correction: Keep interfaces small and focused. Split a large DataProcessor ABC into smaller protocols like DataReader, DataTransformer, and DataWriter. A class can then implement one or more as needed.

Summary

• Duck typing is Python's native, behavior-first approach to polymorphism: your code should work with any object that has the required methods and attributes.
• Inheritance and method overriding provide explicit polymorphism, allowing you to create families of related classes that share a common interface but provide unique implementations.
• Abstract Base Classes (ABCs) use @abstractmethod to enforce that subclasses implement critical methods, preventing runtime errors and clarifying design contracts.
• Protocols offer a modern, flexible way to define interfaces based on structure alone, enabling polymorphism without inheritance—ideal for integrating disparate libraries in data science.
• Applying these concepts enables you to build extensible data pipelines and plugin architectures, where the core system remains stable while new functionality is added seamlessly through interchangeable components.