Skip to main content

Interfaces in Python: Informal and Formal

In Object-Oriented Programming, an interface is a description of the actions an object can do. It's a contract or a blueprint that defines a set of methods that a class must implement. For example, any object that acts as a "Data Parser" should have a .parse() method, regardless of whether it's parsing a PDF, a website, or a text file.

Unlike some other languages, Python does not have a strict interface keyword. Instead, it provides two ways to achieve the goal of defining a common interface: informal interfaces (using conventions and duck typing) and formal interfaces (using the abc module).

📚 Prerequisites​

You should have a solid understanding of classes, inheritance, and polymorphism.

🎯 Article Outline: What You'll Master​

In this article, you will learn:

  • ✅ The Concept of an Interface: Understand why defining a common set of behaviors is useful.
  • ✅ Informal Interfaces: How to use documentation and duck typing to create flexible interfaces.
  • ✅ Formal Interfaces: How to use Abstract Base Classes (ABCs) to create strict, enforceable contracts.
  • ✅ Choosing the Right Approach: When to prefer the flexibility of an informal interface versus the safety of a formal one.

🧠 Section 1: Informal Interfaces (The Pythonic Way)​

The most common way to define an interface in Python is informally. An informal interface is simply a class that defines methods that are meant to be overridden by subclasses, but there is no strict enforcement by the interpreter. It relies on duck typing—if an object has the required methods, it's treated as conforming to the interface.

To signal that a method in an informal interface should be implemented by a subclass, it's common practice to have it raise NotImplementedError.

Example: A Data Exporter Interface Let's define an informal interface for classes that can export data.

# informal_interface.py

class DataExporter:
    """An informal interface for data exporting classes."""
    def export(self, data):
        """Exports the given data."""
        raise NotImplementedError("Subclasses must implement this method.")

class CSVExporter(DataExporter):
    """A concrete implementation that exports data to CSV."""
    def export(self, data):
        print(f"Exporting data to CSV: {data}")

class JSONExporter(DataExporter):
    """A concrete implementation that exports data to JSON."""
    def export(self, data):
        print(f"Exporting data to JSON: {data}")

# --- Let's use them ---
my_data = {"name": "Alice", "age": 30}

csv_exporter = CSVExporter()
json_exporter = JSONExporter()

# We can treat both objects the same way because they follow the interface
exporters = [csv_exporter, json_exporter]
for exporter in exporters:
    exporter.export(my_data)

Pros:

  • Simple and flexible.
  • Doesn't require extra modules or decorators.
  • Relies on Python's natural strength: duck typing.

Cons:

  • No enforcement. If you forget to implement .export() in a subclass, you won't know until you try to call it at runtime, which will raise the NotImplementedError.

💻 Section 2: Formal Interfaces (The Strict Way)​

For larger applications or frameworks where you need to guarantee that a class implements a certain interface, you should use a formal interface. Python provides this through the abc (Abstract Base Classes) module.

We've already seen this when we discussed Abstraction. An ABC can define @abstractmethods. Any concrete subclass that inherits from the ABC must implement all of its abstract methods, otherwise Python will raise a TypeError when you try to create an instance.

Example: A Formal DataSource Interface Let's define a formal contract for any class that can provide data.

# formal_interface.py

from abc import ABC, abstractmethod

class DataSource(ABC):
    """A formal interface for data sources."""
    @abstractmethod
    def get_data(self):
        """Retrieve and return data."""
        pass

class DatabaseSource(DataSource):
    """A concrete implementation for a database."""
    def get_data(self):
        # In a real app, this would connect to a DB
        print("Getting data from the database...")
        return {"id": 1, "data": "db_content"}

class APISource(DataSource):
    """A concrete implementation for a web API."""
    def get_data(self):
        # In a real app, this would make an HTTP request
        print("Getting data from the API...")
        return {"id": 2, "data": "api_content"}

# --- Let's try to create an incomplete class ---
class IncompleteSource(DataSource):
    def some_other_method(self):
        pass

try:
    # This will fail because IncompleteSource doesn't implement get_data()
    my_source = IncompleteSource()
except TypeError as e:
    print(f"Error creating IncompleteSource: {e}")


# --- Creating a valid instance works fine ---
db = DatabaseSource()
print(db.get_data())

Output:

Error creating IncompleteSource: Can't instantiate abstract class IncompleteSource with abstract method get_data
Getting data from the database...
{'id': 1, 'data': 'db_content'}

The TypeError immediately tells the developer they have not fulfilled the DataSource contract.

Pros:

  • Enforces the contract at instantiation time, catching bugs early.
  • Makes the code's intent very clear.
  • Excellent for building frameworks where you need to ensure users' classes will work correctly with your system.

Cons:

  • More verbose (requires imports and decorators).
  • Can be less flexible than duck typing for simple cases.

✨ Conclusion & Key Takeaways​

Interfaces are a way of defining a contract for what a class can do. Python's flexibility allows you to choose the level of strictness that fits your project's needs.

Let's summarize the key takeaways:

  • Interfaces define a set of required methods, promoting polymorphism.
  • Informal Interfaces rely on convention and duck typing. They are simple and flexible, making them very Pythonic for many use cases.
  • Formal Interfaces use the abc module to create a strict contract. They are less flexible but safer, as they guarantee that subclasses implement the required methods.
  • Choose the right tool for the job: For most day-to-day programming, informal interfaces are sufficient. For building large, stable systems or frameworks, formal interfaces provide valuable safety and clarity.

➡️ Next Steps​

We've now explored the major concepts of Object-Oriented Programming. Next, we'll look at some of the more nuanced and powerful features of Python's data model, starting with "Magic Methods (Dunder Methods)," which allow our objects to integrate even more deeply with Python's built-in syntax.

Happy designing!