Learn How to Write Fewer Conditional Statements in Python: Absolute Beginners Tutorial

There is nothing wrong with a small number of if-else statements. The problem appears when you stack many branches together to handle growing lists of conditions. Each new case requires editing the same block of code, making it harder to test, extend, and reason about. This pattern is sometimes called a code smell because it signals that behavior and data are tangled together in a way that creates fragility.

Duck typing is the idea that Python does not check what type an object is before calling a method on it — it just calls the method and trusts the object to know what to do. The name comes from the phrase "if it walks like a duck and quacks like a duck, it is a duck." In Python terms: if the object has the method you want to call, that is all that matters.

In the shape example, the loop calls shape.area() on every object in the list. Python does not verify that each shape is a Circle or a Rectangle before making the call — it just calls .area() and lets the object respond. If you dropped in a completely unrelated LandPlot class that also happened to define area(), it would work in that loop without any modification.

This is why the polymorphic approach eliminates the conditional: instead of the calling code asking "what type is this and which function should I call?", it simply calls the method and each object answers for itself. Duck typing is what makes that possible without requiring every class to formally declare that it implements an interface.

A dispatch table is a plain Python dictionary where keys map to callable objects such as functions or methods. Instead of writing an if-else chain to choose which function to run, you look up the key in the dictionary and call the result. The dictionary acts as a routing table for behavior.

Polymorphism is an object-oriented concept where different classes share the same method name but each class implements the method differently. Instead of writing if type == 'x': do_x() else: do_y(), you call the same method on any object and the object itself handles the correct behavior. The conditional logic moves into the class definition and away from the calling code.

No. A single if or a simple two-branch if-else is completely normal and readable. The techniques in this tutorial are useful specifically when you find yourself adding a new elif every time a new condition arises. That growth pattern is the signal to consider a different architecture.

The Open/Closed Principle (OCP) states that software entities should be open for extension but closed for modification. The term was coined by Bertrand Meyer in his 1988 book Object-Oriented Software Construction and later became the "O" in Robert C. Martin's SOLID principles. In practical terms, adding new behavior should not require editing existing working code. Dispatch tables and polymorphism both support this idea: adding a new case means adding a new dictionary entry or a new class, not rewriting a conditional chain.

Python dictionaries use hash tables internally. According to the CPython Time Complexity wiki, key lookup is O(1) on average — constant time regardless of how many entries exist. (Worst-case is O(n) due to hash collisions, but CPython's randomized hash seeds since Python 3.3 make this extremely rare in practice.) An if-else chain, by contrast, checks each condition in order from top to bottom. For long chains, entries near the end are reached only after every earlier condition has been evaluated — O(n) in the worst case for every lookup.

A missing key raises a KeyError by default. You can handle this with dict.get(key, default_function) to return a fallback callable, or with a try-except block. Providing a sensible default or raising a descriptive error keeps the behavior explicit and avoids silent failures.

functools.singledispatch is a decorator in Python's standard library that implements type-based dispatch. Instead of keying a dictionary on a string, you register handler functions per type and Python automatically routes calls to the right handler based on the type of the first argument. A plain dispatch table keys on any hashable value (usually a string or integer); singledispatch keys specifically on Python types. Both eliminate if-else chains, but singledispatch is the right tool when you are branching on what type an object is rather than on a discrete string key.

When you subclass dict and define a __missing__(self, key) method, Python calls that method automatically whenever a key lookup fails rather than raising a KeyError. This allows a dispatch table to compute or generate a fallback handler dynamically based on the key that was requested. The standard library's collections.defaultdict uses the same hook — the difference is that __missing__ in a custom subclass can inspect the key before deciding what to return, rather than calling a fixed factory function.

Use abc.ABC and @abstractmethod when you want Python to enforce at class-definition time that every subclass implements a required method. Without them, a missing method raises an AttributeError only when the method is actually called at runtime. With them, trying to instantiate a subclass that is missing an abstract method raises a TypeError immediately — before any business logic runs. This is not required for polymorphism to work in Python (duck typing handles that), but it provides an explicit contract that is valuable in larger codebases or team environments.

Yes, and it is a common pattern. The key detail is where you build the dictionary. If you define it as a class-level attribute at class definition time, you cannot reference self yet — so the values must be unbound references like ClassName.method_name, which you then call with handler(self, arg). The more natural approach is to build the dispatch dictionary inside __init__, where self is available, so each value is already a bound method:

class Formatter:
    def __init__(self):
        self._dispatch = {
            "json": self._to_json,
            "csv":  self._to_csv,
            "text": self._to_text,
        }

    def format(self, data, fmt):
        handler = self._dispatch.get(fmt, self._to_text)
        return handler(data)

    def _to_json(self, data): ...
    def _to_csv(self, data):  ...
    def _to_text(self, data): ...

Because the dictionary is built in __init__, each value is already a bound method — calling handler(data) is all you need. The self is already captured. This approach also makes it easy to override the dispatch dictionary in a subclass by reassigning entries in the subclass's own __init__.

The deciding question is whether the different behaviors are fundamentally about data routing or about object identity.

Use a dispatch table when you have a single discrete key — a string, integer, or enum value — that selects a behavior, and the behaviors themselves are short, stateless functions that do not need to carry their own data. The discount calculator is a good example: each handler is a pure calculation, and the key is just a string label.

Use polymorphism when each "case" has its own state, its own initialization logic, or several related methods that naturally belong together. A Circle needs to store a radius, expose an area(), and potentially a perimeter() and a bounding_box(). Grouping all of that into a class is cleaner than managing parallel dictionaries for each method. A rough rule: if you find yourself building multiple dispatch tables that all key on the same value, you probably want a class hierarchy instead.

Both patterns can coexist. A common real-world combination is a dispatch table whose values are instances of polymorphic classes — the table handles routing, and each class handles its own behavior.

Dispatch tables work fine with any number of arguments — the dictionary just stores the function reference, and you call it with however many arguments you need. All handlers should accept the same signature so the calling code stays uniform:

def apply_student(price, tax_rate, member_years):
    base = price * 0.80
    return base * (1 + tax_rate) * (0.99 ** member_years)

def apply_senior(price, tax_rate, member_years):
    return price * 0.75 * (1 + tax_rate)

DISCOUNTS = {
    "student": apply_student,
    "senior":  apply_senior,
}

handler = DISCOUNTS.get(customer_type, lambda p, t, y: p)
result  = handler(price, tax_rate, member_years)

If the handlers genuinely need different signatures, the usual solution is to pass a context object or a dictionary of named parameters instead of positional arguments, keeping the call site as handler(context) regardless of what each handler unpacks from it.

Significantly. A long if-elif-else chain forces you to test one monolithic function by exercising every branch through its input. Adding a new branch means adding new test cases to an already large test function, and a mistake in one branch can mask failures in others.

When each branch is its own function, you test each handler in complete isolation — one test function per handler, with no need to thread a value through a conditional to reach the code you care about. The routing function itself (the two-line dispatcher) needs only a handful of tests: one for a known key, one for an unknown key hitting the default, and one verifying the return value is passed through correctly. That is three tests covering what was previously one untestable tangle.

Polymorphism gives the same benefit at the class level: each class is tested independently, and the calling code that iterates over objects and calls .area() is tested separately from the area calculations themselves. Adding a new shape class does not invalidate any existing test.

Yes, but only for very short expressions. A lambda is an anonymous function, so {"student": lambda p: p * 0.80} is valid Python. The problem is readability: lambda bodies cannot span multiple lines, cannot contain statements like if or return with early exits, and produce opaque tracebacks when something goes wrong. For anything more than a one-expression calculation, a named function is almost always the better choice.

A practical rule: if the lambda fits on the same line as the dictionary key and you can read it at a glance, it is fine. If you find yourself nesting logic inside a lambda, extract a named function instead. The dispatch table pattern is specifically designed to make behavior visible — a wall of lambdas defeats that purpose.

functools.singledispatch dispatches on the type of the first positional argument. When you use it inside a class, the first argument is self — which is always an instance of the class — so every call routes to the base implementation, never to a registered type handler. The dispatch never fires as intended.

functools.singledispatchmethod, added in Python 3.8, is designed specifically for use inside a class. It skips self (or cls for class methods) and dispatches on the type of the next argument instead. Use singledispatch for standalone functions and singledispatchmethod for methods inside a class definition. Confusing the two is one of the most reliable sources of silent misbehavior when first learning type-based dispatch.

Enums are a better choice than plain strings whenever the set of valid keys is fixed and known at development time. A string key lets a typo slip through silently — "stuednt" simply misses the dispatch table and hits the default. An enum key raises a ValueError at the point where the invalid value is created, not deep inside the routing logic.

from enum import Enum, auto

class CustomerType(Enum):
    STUDENT  = auto()
    SENIOR   = auto()
    EMPLOYEE = auto()
    VIP      = auto()

DISCOUNTS = {
    CustomerType.STUDENT:  lambda p: p * 0.80,
    CustomerType.SENIOR:   lambda p: p * 0.75,
    CustomerType.EMPLOYEE: lambda p: p * 0.60,
    CustomerType.VIP:      lambda p: p * 0.50,
}

handler = DISCOUNTS.get(customer_type, lambda p: p)
result  = handler(price)

Enum members are also hashable, so they work as dictionary keys without any additional setup. In a codebase where customer types come from a configuration file or user input as strings, you can convert the string to an enum early — at the boundary of your system — and let the rest of the code work with the safer enum representation throughout.

It depends on what the nesting is doing. If the outer condition selects a category and the inner condition selects a sub-behavior within that category, a two-level dispatch table handles this cleanly — the outer key maps to a second dictionary, and that dictionary maps the inner key to the handler:

HANDLERS = {
    "image": {
        "resize":  resize_image,
        "convert": convert_image,
    },
    "video": {
        "trim":    trim_video,
        "convert": convert_video,
    },
}

handler = HANDLERS.get(file_type, {}).get(action, unknown_action)
handler(file)

If the nesting involves unrelated conditions — for example, an outer check on a range value and an inner check on a string key — a flat dispatch table may not fit neatly. In that case, consider whether the structure is better expressed with a polymorphic class hierarchy, where each class handles its own internal complexity rather than exposing it to the calling code.

Nesting dispatch tables more than two levels deep is usually a warning sign that the problem needs to be reframed, not that you need deeper nesting.

A dispatch table is the right choice when routing is based on a single discrete key and the number of cases is expected to grow. A match statement (introduced in Python 3.10 via PEP 634) is better suited for a different class of problem: when you need to destructure data and match against its shape, type, and content simultaneously.

Consider parsing a command that might arrive as a tuple in different forms:

match command:
    case ("quit",):
        quit_game()
    case ("go", direction):
        go(direction)
    case ("pick", item) if item in inventory:
        pick_up(item)
    case _:
        print("Unknown command")

A dispatch table cannot express the guard clause if item in inventory or capture the direction variable in a single step. For matching against nested data structures, unpacking values, or applying guard conditions, match is more expressive. For routing to one of several handlers based on a simple string or enum key — particularly when new handlers will be added over time — a dispatch table is the cleaner architecture because it does not require touching existing code to extend it.

They solve related problems but are not the same thing. Python's match statement was introduced in Python 3.10 via PEP 634 (authored by Brandt Bucher and Guido van Rossum). It is structural pattern matching that can inspect the shape, type, and content of data — not just compare values. Dispatch tables and polymorphism are code organization strategies that move conditional logic into data structures or class hierarchies. Both can reduce explicit if-else branches, but match is best suited for deconstructing nested data structures (like JSON or ASTs), while dispatch tables shine for routing on a single discrete key.