DEV Community: Rajesh Vemulakonda

Duck Typing in Python: Powerful Feature or Hidden Trap?

Rajesh Vemulakonda — Tue, 04 Aug 2026 09:32:01 +0000

Introduction

Python often follows a simple idea:

If an object provides the behavior we need, why should we care what type it is?

Consider this function:

def make_sound(animal):
    animal.speak()

It doesn't check whether animal inherits from a particular class. It simply expects the object to provide speak().

So these unrelated classes work perfectly:

class Dog:
    def speak(self):
        print("Woof")


class Cat:
    def speak(self):
        print("Meow")

make_sound(Dog())
make_sound(Cat())

This flexibility is one of Python's strengths and is commonly known as duck typing.

But there's another side to it.

What happens if we pass an object that doesn't provide the expected behavior?

class Fish:
    pass


make_sound(Fish())

The flexibility suddenly becomes a runtime error:

AttributeError: 'Fish' object has no attribute 'speak'

That raises an interesting question:

Is duck typing one of Python's most powerful features, or can that same flexibility become a hidden trap?

The answer is both.

In this article, we'll explore why duck typing makes Python code flexible and extensible, where it can introduce runtime failures, and how to decide when that flexibility is worth using.

What Is Duck Typing?

Duck typing is an approach where an object's suitability is determined by the behavior it provides, rather than by its class or inheritance hierarchy.

The idea comes from the well-known saying:

If it walks like a duck and quacks like a duck, then it can be treated as a duck.

In Python terms, instead of asking:

Is this object a particular type?

we often care more about:

Does this object support the operation I need?

Our make_sound() function follows exactly this idea: it doesn't require the object to inherit from a particular base class. It only expects the object to provide a compatible speak() method.

For example:

class Robot:
    def speak(self):
        print("Beep")


make_sound(Robot())

Output:

Beep

Robot doesn't share a parent class with Dog or Cat, but that doesn't matter. It provides the expected behavior, so it works.

That's the central idea behind duck typing:

What an object can do matters more than what type it is.

This allows Python code to work with different objects without forcing them into a common inheritance hierarchy.

That flexibility is exactly what makes duck typing powerful.

Why Duck Typing Is Powerful

Duck typing allows functions to work with different objects without requiring them to share a common base class.

Consider a simple exporter:

class PDFExporter:
    def export(self, data):
        print("Exporting PDF")


class CSVExporter:
    def export(self, data):
        print("Exporting CSV")

A generic function can work with either:

def export_data(exporter, data):
    exporter.export(data)

Usage:

export_data(PDFExporter(), data)
export_data(CSVExporter(), data)

export_data() doesn't need to know the concrete type of the exporter. It only expects an object that provides a compatible export() method.

Less Coupling

Because the function depends on behavior rather than a specific class hierarchy, the objects remain loosely coupled.

There is no requirement such as:

class PDFExporter(Exporter):
    ...

just to make PDFExporter usable by export_data().

Easy Extension

Suppose we later need JSON support:

class JSONExporter:
    def export(self, data):
        print("Exporting JSON")

It immediately works with the existing function:

export_data(JSONExporter(), data)

No changes to export_data() are required. We extend the system by adding new behavior rather than modifying code that already works.

This also aligns naturally with the Open/Closed Principle (OCP):

Software entities should be open for extension but closed for modification.

Duck typing can help support this principle by allowing new compatible objects to work with existing code without requiring changes to that code.

For a deeper look at this idea, see my companion article:

Stop Editing Working Code: Understanding the Open/Closed Principle in Python

Together, loose coupling and easy extension make duck typing a powerful design tool.

If an object provides the expected behavior, it can participate.

But that flexibility comes with a trade-off.

What happens when an object doesn't provide the behavior we expect?

That's where duck typing can become a hidden trap.

The Hidden Trap: Errors Appear at Runtime

That trade-off becomes clear when an object doesn't provide the behavior the code expects.

Consider our exporter:

def export_data(exporter, data):
    exporter.export(data)

The function assumes that the object it receives provides an export() method.

Now suppose we pass an incompatible object:

class Logger:
    def log(self, message):
        print(message)

export_data(Logger(), data)

Logger doesn't provide export(), so the program fails at runtime:

AttributeError: 'Logger' object has no attribute 'export'

That's one of the risks of duck typing.

The function can be called with the object without requiring it to belong to a particular class hierarchy. But that also means incompatibility may not become apparent until the expected operation is actually performed.

The Problem Grows in Larger Systems

In a small example, the mistake is obvious.

In a larger application, an incompatible object might travel through several functions or components before the missing behavior is finally used.

The error then appears far from where the wrong object originally entered the system, making the problem harder to trace.

Duck typing therefore gives us freedom, but also places responsibility on developers to understand the behavioral expectations of their code.

Flexibility is powerful when the expected behavior is clear. It becomes risky when that contract is only implicit.

And a missing method isn't the only possible problem.

Sometimes an object provides the expected method name, yet its behavior is still incompatible.

That's an even subtler trap.

When Behavior Looks Compatible but Isn't

Duck typing is not only about whether a method exists.

The method must also be compatible with how the caller expects to use it.

Consider our exporter again:

def export_data(exporter, data):
    exporter.export(data)

Now suppose we create this class:

class ReportExporter:
    def export(self):
        print("Exporting report")

At first glance, ReportExporter appears compatible because it provides an export() method.

But this call:

export_data(ReportExporter(), data)

fails:

TypeError: ReportExporter.export() takes 1 positional argument but 2 were given

The method exists, but its signature doesn't match what export_data() expects.

Same Method Name, Different Meaning

The problem can be even more subtle when the signature matches but the behavior doesn't.

class Database:
    def export(self, data):
        print("Removing exported records from database")

Technically, this object provides:

export(data)

But its behavior may violate what the caller expects from an exporter.

This highlights an important point:

Duck typing depends on a behavioral contract, not just matching method names.

That contract may include the method name, accepted arguments, return value, side effects, and expected meaning of the operation.

When those expectations remain implicit, duck typing can make incorrect objects appear compatible until something goes wrong.

So how can we keep the flexibility of duck typing while making those expectations clearer?

That's where safer design practices can help.

Making Duck-Typed Code Safer

Duck typing doesn't have to mean giving up clarity or safety.

The key is to make the expected behavior as clear as possible.

Use Clear Behavioral Expectations

A function should make its requirements easy to understand:

def export_data(exporter, data):
    exporter.export(data)

Here, the expectation is simple: exporter must provide an export() method that accepts data.

Good naming and documentation can make such contracts easier for developers to understand.

Make Expectations Explicit With Type Hints

Type hints can make expectations more explicit and allow static type checkers to catch certain mistakes before runtime.

For example, Python's typing.Protocol can describe the behavior an object is expected to provide without requiring inheritance from a particular base class.

Conceptually, we can express:

Any object that provides:

export(data)

can be treated as an exporter.

This preserves the flexibility of duck typing while making the expected interface clearer.

We'll explore Protocol in detail in a separate article.

Test the Expected Behavior

Tests are especially valuable when code relies on behavioral contracts.

If several objects are expected to satisfy the same behavioral contract, test each implementation against those expectations.

This helps catch problems such as:

Missing methods
Incompatible method signatures
Unexpected return values
Incorrect behavior

Duck typing works best when flexibility is combined with clear expectations and good testing.

The goal isn't to remove duck typing's flexibility, but to make its implicit contracts easier to understand and verify.

When Duck Typing Is a Good Choice

Duck typing works particularly well when different objects naturally support the same behavior without needing a shared inheritance hierarchy.

When Behavior Matters More Than Type

If a function only needs a specific capability, requiring a particular class may add unnecessary coupling.

For example:

def save(writer, data):
    writer.write(data)

The function doesn't need to know whether writer is a file object, an in-memory buffer, or some other compatible object.

It only needs:

write(data)

This keeps the function flexible and focused on the behavior it actually requires.

When Working With Small, Clear Interfaces

Duck typing is especially effective when the expected interface is simple and easy to understand.

A requirement such as:

Object must provide:

send(message)

is easier to reason about than an object expected to provide many loosely defined methods.

The smaller and clearer the behavioral contract, the easier duck typing is to use safely.

When Extensibility Matters

Duck typing also works well when new implementations are likely to be added over time.

If a new object provides the expected behavior, existing code can often work with it without modification.

This makes duck typing a natural choice for extensible systems where flexibility is valuable and the expected behavioral contract remains clear.

Duck typing is therefore a strong choice when:

The required behavior is small and clearly defined.
Different types naturally provide the same operation.
A shared inheritance hierarchy would add little value.
Extensibility and loose coupling are important.

But flexibility isn't always the right priority.

When behavioral expectations become larger, more complex, or harder to discover, a more explicit contract may be a better choice.

When to Prefer a More Explicit Contract

Duck typing works well when the expected behavior is small and obvious.

But as a system grows, those expectations can become harder to understand and maintain.

Suppose a component expects an object to provide several operations:

connect()
send(data)
receive()
close()

With a simple duck-typed design, that contract may remain implicit in documentation, tests, or the assumptions made by the surrounding code.

As the interface grows, developers may need a clearer way to understand what an object is expected to provide.

When Expectations Become Complex

A more explicit contract can be useful when:

Several methods must work together.
Method signatures and return types matter.
Many developers work with the same interface.
Incorrect implementations would be difficult to detect.
Static type checking is important to the project.

The goal isn't to abandon duck typing.

It's to make the expected behavior easier to discover and verify.

Python Gives Us Options

Depending on the design, Python provides several ways to make contracts more explicit, including:

Abstract Base Classes
Type hints
typing.Protocol

Abstract base classes can define an explicit inheritance-based interface.

Protocol is particularly interesting because it can describe the expected behavior without requiring explicit inheritance, making it a natural companion to duck typing.

We won't explore Protocol in detail here, but it leads to an interesting question:

Can we keep the flexibility of duck typing while gaining stronger type checking and clearer contracts?

That's a topic worth exploring on its own.

The important point is that neither approach is universally better.

Duck typing offers flexibility and loose coupling.

Explicit contracts offer clarity and stronger ways to express and check expectations.

Good design comes from choosing the level of structure that fits the problem.

Key Takeaways

Duck typing is one of Python's most flexible features, but that flexibility comes with responsibility.

Here are the key ideas:

Duck typing focuses on behavior, not inheritance.

If an object provides the expected behavior, it can often be used regardless of its class hierarchy.

It promotes flexibility and loose coupling.

Functions can work with different object types without requiring them to inherit from a common base class.

The contract is often implicit.

An object may appear compatible but still fail because of a missing method, an incompatible signature, or unexpected behavior.

Some compatibility problems surface only at runtime.

Without clearer contracts or static checking, incompatibilities may remain unnoticed until the relevant code executes.

Duck typing works best with small, clear interfaces.

The easier the expected behavior is to understand, the easier duck typing is to use effectively.

More complex systems may benefit from explicit contracts.

Abstract base classes, type hints, and Protocol can make behavioral expectations clearer when additional structure is useful.

The central idea is simple:

Duck typing is powerful when its behavioral contract is clear. It becomes a hidden trap when that contract is misunderstood or left ambiguous.

Conclusion

So, is duck typing in Python a powerful feature or a hidden trap?

The answer is:

It can be both.

Duck typing contributes to Python's flexibility. It allows different objects to work with the same code based on the behavior they provide, without forcing them into a common inheritance hierarchy.

But that flexibility comes with a trade-off.

When behavioral expectations are unclear, incompatible objects may fail only at runtime. And as those expectations become more complex, implicit contracts can become harder to understand and maintain.

The goal, therefore, isn't to avoid duck typing or use it everywhere.

It's to recognize when its flexibility helps and when additional structure would make the code clearer and safer.

For small, well-understood behavioral contracts, duck typing can be elegant and powerful. For larger or more complex contracts, tools such as type hints, abstract base classes, and Protocol can make expectations more explicit.

Perhaps the best way to think about duck typing is:

Flexibility is a strength when the contract is clear. Without clarity, the same flexibility can become a liability.

And that leads naturally to another question:

Can Python preserve the flexibility of duck typing while making behavioral contracts explicit and statically checkable?

That's where typing.Protocol enters the picture.

Does Polymorphism Always Require Inheritance? A Python Perspective

Rajesh Vemulakonda — Mon, 20 Jul 2026 07:03:36 +0000

Many developers learn polymorphism through inheritance and assume the two concepts are inseparable.

But does polymorphism actually require inheritance?

Python provides a surprising answer.

Introduction

Most OOP tutorials introduce polymorphism through inheritance using a base class, derived classes, and method overriding.

As a result, many developers naturally form a mental model like this:

Inheritance
      ↓
Polymorphism

Over time, this often leads to a common assumption:

Polymorphism requires inheritance.

But is that really true?

Python approaches polymorphism differently.

In many cases, objects can participate in polymorphic behavior without inheriting from a common parent class. What matters is not where an object comes from, but what it can do.

This leads to an important realization:

Inheritance can enable polymorphism, but it is not always required.

In this article, we'll explore the relationship between inheritance and polymorphism and see how Python's duck typing allows polymorphism to exist even without inheritance.

The Common Assumption

If you've studied object-oriented programming, you've probably seen examples like this:

class Animal:
    def speak(self):
        pass


class Dog(Animal):
    def speak(self):
        print("Woof")


class Cat(Animal):
    def speak(self):
        print("Meow")

A function can then work with any Animal object:

def make_sound(animal):
    animal.speak()

Usage:

make_sound(Dog())
make_sound(Cat())

Output:

Woof
Meow

This is a classic example of polymorphism. The same function works with different object types, and each object provides its own implementation of speak().

Because examples like these are so common, many developers naturally form the following mental model:

Inheritance
      ↓
Method Overriding
      ↓
Polymorphism

Over time, this often becomes:

Polymorphism requires inheritance.

The assumption is understandable because inheritance appears in almost every introductory explanation of polymorphism.

But inheritance and polymorphism are not the same thing.

Inheritance is one way to achieve polymorphism, but is it the reason polymorphism works?

Let's examine the traditional inheritance-based approach more closely.

Classic Polymorphism Through Inheritance

Traditionally, polymorphism is demonstrated using inheritance.

Consider the following example:

class Animal:

    def speak(self):
        raise NotImplementedError


class Dog(Animal):

    def speak(self):
        print("Woof")


class Cat(Animal):

    def speak(self):
        print("Meow")

A function can work with any object derived from Animal:

def make_sound(animal):
    animal.speak()

Usage:

make_sound(Dog())
make_sound(Cat())

Output:

Woof
Meow

The function doesn't need to know whether it received a Dog or a Cat. It simply calls:

animal.speak()

Each object provides its own implementation, allowing the same operation to produce different behavior. That's the essence of polymorphism.

Here, inheritance provides a common interface that makes this possible.

Why This Works

Inheritance establishes a common parent class:

Animal
   │
   ├── Dog
   └── Cat

Both Dog and Cat implement:

speak()

allowing make_sound() to work with either object.

But this raises an important question:

Does make_sound() really require a common parent class, or does it simply require an object that provides speak()?

That distinction is important because if polymorphism is fundamentally about behavior, inheritance may not be the real reason the code works.

To answer that, we first need to understand what polymorphism really is.

What Is Polymorphism Really?

At its core, polymorphism is the ability of different objects to respond to the same operation in their own way.

For example:

class Dog:

    def speak(self):
        print("Woof")


class Cat:

    def speak(self):
        print("Meow")

Both classes provide:

speak()

but each produces different behavior.

Now consider this function:

def make_sound(animal):
    animal.speak()

Usage:

make_sound(Dog())
make_sound(Cat())

Output:

Woof
Meow

The same function works with different objects because each provides its own implementation of speak(). That's polymorphism.

A useful way to think about it is:

Same Operation
       +
Different Implementations
       =
Polymorphism

Notice that this definition says nothing about inheritance.

The important question is not:

Do these objects inherit from the same parent class?

Instead, ask:

Can these objects respond to the same operation?

If the answer is yes, polymorphism is possible.

The Key Idea

Many developers think of polymorphism like this:

Inheritance
      ↓
Polymorphism

A more accurate view is:

Same Operation
       +
Different Implementations
       =
Polymorphism

The focus is not on whether objects share a parent class, but on whether they can respond to the same operation.

Polymorphism Is About Behavior

Consider a notification system:

class EmailNotifier:
    def send(self):
        print("Sending email")


class SMSNotifier:
    def send(self):
        print("Sending SMS")


class PushNotifier:
    def send(self):
        print("Sending push notification")

A generic function can work with all of them:

def notify(notifier):
    notifier.send()

The function only cares that the object provides:

send()

This illustrates an important point: polymorphism depends on behavior, not the specific type of object.

If behavior is what matters, do we really need inheritance to achieve polymorphism?

Python's answer is:

Not always.

And that's where duck typing enters the picture.

Polymorphism Through Duck Typing

One of Python's most distinctive features is duck typing, often summarized as:

If it walks like a duck and quacks like a duck, then it can be treated as a duck.

Instead of focusing on an object's inheritance hierarchy, Python focuses on its behavior.

In other words, the question becomes:

Does this object provide the behavior I need?

A Polymorphic Example Without Inheritance

Consider the following classes:

class Dog:
    def speak(self):
        print("Woof")


class Cat:
    def speak(self):
        print("Meow")


class Cow:
    def speak(self):
        print("Moo")

Notice that none of these classes inherit from a common parent.

A generic function can still work with all of them:

def make_sound(animal):
    animal.speak()

Usage:

make_sound(Dog())
make_sound(Cat())
make_sound(Cow())

Output:

Woof
Meow
Moo

The function works because every object provides speak(). It depends on behavior, not inheritance.

Adding New Types Requires No Changes

Suppose we need to support ducks.

We can simply add:

class Duck:
    def speak(self):
        print("Quack")

Usage:

make_sound(Duck())

Output:

Quack

No changes are required to make_sound(). We simply introduce another object that provides the expected behavior.

The Real Source of Polymorphism

Notice that make_sound() never checks whether an object inherits from Animal, for example:

isinstance(animal, Animal)

Its only requirement is that the object supports:

animal.speak()

This reveals an important insight:

The true source of polymorphism is shared behavior, not shared ancestry.

Inheritance can provide that behavior, but so can duck typing.

At this point, we can answer the original question:

Does polymorphism always require inheritance?

In Python, the answer is:

No.

Different objects can participate in polymorphic behavior as long as they support the same operation, even without an inheritance relationship.

When Inheritance Is Still Useful

At this point, it might be tempting to conclude:

If polymorphism can exist without inheritance, then inheritance is unnecessary.

That would be the wrong conclusion.

The lesson is not:

Avoid inheritance

The lesson is:

Use inheritance when it solves a problem

Shared Behavior

Consider the following example:

class Animal:

    def eat(self):
        print("Eating")

    def sleep(self):
        print("Sleeping")


class Dog(Animal):

    def speak(self):
        print("Woof")


class Cat(Animal):

    def speak(self):
        print("Meow")

Here, Dog and Cat inherit common behavior from Animal instead of duplicating the same code, improving maintainability and reducing repetition.

"Is-A" Relationships

Inheritance is often appropriate when one type is a specialized form of another:

Dog is an Animal

Manager is an Employee

SavingsAccount is an Account

In such cases, inheritance naturally models the domain.

Inheritance and Polymorphism Can Work Together

Inheritance and polymorphism often complement each other:

class PaymentMethod:

    def process(self, amount):
        raise NotImplementedError


class CreditCard(PaymentMethod):

    def process(self, amount):
        print(f"Processing {amount} using credit card")


class UPI(PaymentMethod):

    def process(self, amount):
        print(f"Processing {amount} using UPI")

A generic function can work with any payment method:

def make_payment(method, amount):
    method.process(amount)

This is a perfectly valid example of inheritance-based polymorphism.

The Real Lesson

Inheritance and polymorphism are related, but they solve different problems:

Inheritance
      ↓
Code Reuse and Relationships

Polymorphism
      ↓
Behavioral Flexibility

Inheritance can enable polymorphism, but it is not a prerequisite for it.

Understanding this distinction helps us choose the right tool for the problem at hand.

Key Takeaways

Let's return to the original question:

Does polymorphism always require inheritance?

The answer is:

No. Polymorphism does not require inheritance.

Throughout this article, we've seen that:

✅ Inheritance and polymorphism are different concepts.

Inheritance models relationships and promotes code reuse, while polymorphism enables different objects to respond to the same operation.

✅ Inheritance can enable polymorphism.

Traditional OOP often achieves polymorphism through inheritance and method overriding.

✅ Duck typing also enables polymorphism.

In Python, objects don't need a common parent class—they simply need to provide the expected behavior.

✅ Behavior is the key.

Same Operation
       +
Different Implementations
       =
Polymorphism

Focus on what objects can do, not necessarily what they inherit from.

✅ Inheritance is still valuable.

Use inheritance to model relationships, share behavior, and reduce duplication.

The Most Important Insight

Many developers start with this mental model:

Inheritance
      ↓
Polymorphism

A more accurate view is:

Inheritance
      ↓
One Way to Enable Polymorphism

That's perhaps the most important lesson Python teaches about polymorphism.

Conclusion

Polymorphism is often taught through inheritance, making it easy to assume the two concepts are inseparable.

As we've seen, inheritance is one way to enable polymorphism—but it is not the only way.

Python demonstrates this particularly well through duck typing, where objects can participate in polymorphic behavior simply by providing the expected methods.

This leads to an important realization:

Polymorphism is fundamentally about behavior, not inheritance.

Inheritance remains a valuable tool for code reuse and modeling relationships between classes. It should be used because it solves those problems—not because polymorphism depends on it.

The next time you design a system, ask yourself:

Do these objects need a common parent class, or do they simply need to provide the same behavior?

Perhaps that's the most Pythonic lesson of all:

What an object can do is often more important than what it inherits from.

Stop Editing Working Code: Understanding the Open/Closed Principle in Python

Rajesh Vemulakonda — Fri, 17 Jul 2026 05:52:11 +0000

Every time a new requirement arrives, do you find yourself opening the same function and adding another elif block?

If yes, your code may be signaling a design problem.

Most software bugs aren't caused by adding new features.

They're caused by modifying existing features that were already working.

The Open/Closed Principle (OCP) is one of the most effective ways to reduce that risk.

Consider a simple export utility:

def export(data, file_type):

    if file_type == "pdf":
        export_pdf(data)

    elif file_type == "csv":
        export_csv(data)

A few weeks later:

elif file_type == "json":
    export_json(data)

Then:

elif file_type == "xml":
    export_xml(data)

Then:

elif file_type == "html":
    export_html(data)

The code still works.

The problem is that every new requirement forces us to modify existing, tested code.

As the application grows, this pattern increases:

Maintenance effort
Regression testing
Risk of introducing bugs

This is exactly the problem the Open/Closed Principle (OCP) tries to solve.

Software entities should be open for extension but closed for modification.

In simple terms:

Add new behavior without repeatedly editing code that already works.

Most discussions stop at inheritance and polymorphism. Python, however, provides several additional ways to achieve OCP that often feel more natural.

Let's explore them.

OCP Through Duck Typing

Many OOP examples start by creating a base class:

class Exporter:
    def export(self, data):
        pass

and then inheriting from it.

Python often doesn't need that.

class PDFExporter:

    def export(self, data):
        print("Exporting PDF")

class CSVExporter:

    def export(self, data):
        print("Exporting CSV")

class JSONExporter:

    def export(self, data):
        print("Exporting JSON")

A generic function can simply rely on behavior:

def export_data(exporter, data):
    exporter.export(data)

Usage:

export_data(PDFExporter(), data)
export_data(CSVExporter(), data)
export_data(JSONExporter(), data)

The function doesn't care about inheritance.

It only cares that the object provides an export() method.

Need XML support?

class XMLExporter:

    def export(self, data):
        print("Exporting XML")

No existing code changes.

That's extension without modification.

OCP Through First-Class Functions

Python treats functions as first-class objects.

That means behavior itself can become an extension point.

def export_pdf(data):
    print("Exporting PDF")

def export_csv(data):
    print("Exporting CSV")

def export_json(data):
    print("Exporting JSON")

Generic exporter:

def export_data(exporter, data):
    exporter(data)

Usage:

export_data(export_pdf, data)
export_data(export_csv, data)
export_data(export_json, data)

Adding support for XML becomes trivial:

def export_xml(data):
    print("Exporting XML")

export_data(export_xml, data)

Again, existing code remains untouched.

OCP Through Registration Decorators

As systems grow, we often need a way to discover available functionality automatically.

Decorators can act as registration mechanisms.

Start with a registry:

exporters = {}

Create a registration decorator:

def register(file_type):

    def decorator(func):
        exporters[file_type] = func
        return func

    return decorator

@register("pdf")
def export_pdf(data):
    print("Exporting PDF")

@register("csv")
def export_csv(data):
    print("Exporting CSV")

Dispatcher:

def export(data, file_type):
    exporters[file_type](data)

Adding a new format becomes:

@register("xml")
def export_xml(data):
    print("Exporting XML")

No dispatcher changes required.

This is the foundation of many plugin-style architectures.

OCP Through `functools.singledispatch`

Python's standard library includes an elegant extension mechanism called singledispatch.

Without it:

def export(data):

    if isinstance(data, list):
        ...

    elif isinstance(data, dict):
        ...

    elif isinstance(data, str):
        ...

With singledispatch:

from functools import singledispatch


@singledispatch
def export(data):
    raise TypeError("Unsupported type")

@export.register
def _(data: list):
    print("Exporting list")

@export.register
def _(data: dict):
    print("Exporting dictionary")

@export.register
def _(data: str):
    print("Exporting string")

Need tuple support?

@export.register
def _(data: tuple):
    print("Exporting tuple")

No changes to the original function.

Just register another implementation.

When OCP Becomes Overengineering

Not every problem needs abstractions.

This code is perfectly fine:

if age >= 18:
    print("Eligible")
else:
    print("Not Eligible")

Creating:

class EligibilityStrategy:
    ...

would likely make the code worse, not better.

The goal is not to eliminate every conditional statement.

The goal is to identify areas that genuinely evolve over time.

Examples include:

File exporters
Payment processors
Notification systems
Authentication providers
Data parsers

These are natural candidates for extension.

Want the Full Version?

This article focuses on Python-specific techniques for applying the Open/Closed Principle.

For a deeper dive covering:

Inheritance
Polymorphism
Strategy Pattern
Practical design trade-offs
A decision checklist
Detailed examples

see the full companion guide on GitHub:

https://github.com/Vemulakonda559/open-closed-principle-python

Key Takeaway

Many developers associate the Open/Closed Principle with inheritance.

Python offers a broader perspective.

We can achieve OCP through:

Duck Typing
First-Class Functions
Registration Decorators
functools.singledispatch

The common theme is always the same:

Add new behavior without repeatedly modifying existing behavior.

The next time you find yourself adding another branch to a growing if-elif chain, pause and ask:

Can this be extended instead?

That question is often the first step toward writing code that is easier to maintain, test, and evolve.

Why Does obj.method() Automatically Receive self? A Deep Dive into Python Method Binding

Rajesh Vemulakonda — Wed, 15 Jul 2026 04:13:27 +0000

Every Python programmer writes:

obj.method()

But have you ever wondered why Python automatically passes self?

While studying Python internals, I explored how method binding works, how descriptors participate in attribute access, and how Python creates bound method objects behind the scenes.

This article documents that learning journey.

A Simple Example

class Demo:
    def hello(self):
        print("Hello")

obj = Demo()

obj.hello()

We didn't pass self.
So where did it come from?

Demo.hello(obj)

This produces the same result.

This is the first clue that Python is doing something special behind the scenes.

If obj.hello() and Demo.hello(obj) behave the same way, then Python must somehow be attaching obj automatically when we access the method through an instance.

When Python evaluates:

obj.hello

it does not immediately execute the function.

Instead, Python performs attribute lookup and invokes the descriptor protocol.

The function object is transformed into a bound method object that already contains a reference to obj.

When the method is later called, obj is automatically supplied as the first argument (self).

obj.hello
     ↓
function.\_\_get\_\_(obj, Demo)
     ↓
Bound Method Created
     ↓
self Attached
     ↓
Method Executes

Complete Notes

This article provides a brief overview.

The complete experiments, explanations, and code examples are available in the GitHub repository:

https://github.com/Vemulakonda559/python-method-binding

DEV Community: Rajesh Vemulakonda

Duck Typing in Python: Powerful Feature or Hidden Trap?

Introduction

What Is Duck Typing?

Why Duck Typing Is Powerful

Less Coupling

Easy Extension

The Hidden Trap: Errors Appear at Runtime

The Problem Grows in Larger Systems

When Behavior Looks Compatible but Isn't

Same Method Name, Different Meaning

Making Duck-Typed Code Safer

Use Clear Behavioral Expectations

Make Expectations Explicit With Type Hints

Test the Expected Behavior

When Duck Typing Is a Good Choice

When Behavior Matters More Than Type

When Working With Small, Clear Interfaces

When Extensibility Matters

When to Prefer a More Explicit Contract

When Expectations Become Complex

Python Gives Us Options

Key Takeaways

Conclusion

Does Polymorphism Always Require Inheritance? A Python Perspective

Introduction

The Common Assumption

Classic Polymorphism Through Inheritance

Why This Works

What Is Polymorphism Really?

The Key Idea

Polymorphism Is About Behavior

Polymorphism Through Duck Typing

A Polymorphic Example Without Inheritance

Adding New Types Requires No Changes

The Real Source of Polymorphism

When Inheritance Is Still Useful

Shared Behavior

"Is-A" Relationships

Inheritance and Polymorphism Can Work Together

The Real Lesson

Understanding this distinction helps us choose the right tool for the problem at hand.

Key Takeaways

The Most Important Insight

Conclusion

Stop Editing Working Code: Understanding the Open/Closed Principle in Python

OCP Through Duck Typing

OCP Through First-Class Functions

OCP Through Registration Decorators

OCP Through functools.singledispatch

When OCP Becomes Overengineering

Want the Full Version?

Key Takeaway

Why Does obj.method() Automatically Receive self? A Deep Dive into Python Method Binding

A Simple Example

Complete Notes

OCP Through `functools.singledispatch`