7 Advanced Python Design Patterns for Data Scientists

Most training functions start out small and readable. Give one six months in a shared repository, though, and it accumulates model-specific conditionals, data-source branches, a hand-rolled cache check and logging calls to three destinations. No single line is wrong. The function has simply absorbed another branch every time the project changed, and now every caller inherits the whole pile.

KDnuggets has already covered Python patterns for intermediate data scientists, where pipeline, factory and decorator handle the everyday cases. This article starts where that guide stops: seven patterns, each matched to one pressure that shows up once a notebook becomes code other people depend on.

One rule of restraint applies to everything below. If nothing else will ever call the code, a pattern is ceremony, and a plain function remains the better tool. Patterns pay for themselves only when they remove a source of change that keeps coming back.

1. Swap Evaluation Logic With Strategy

An experiment runner that picks scoring with if metric == "accuracy" grows a new branch for every metric the team adopts. Strategy removes the branching by making the scoring behavior a value the caller passes in:

def evaluate(y_true, y_pred, scorer):
        return scorer(y_true, y_pred)

evaluate(y_true, y_pred, accuracy)          # 0.6
evaluate(y_true, y_pred, recall_pos)        # 0.667

Both calls run against the same five predictions, but the runner never learns which policy it executed, and that ignorance is the payoff. Each scorer can now be tested on its own, and adding a new one means writing a function rather than editing the experiment. Strategy also gets confused with Command often enough that the line is worth drawing here. Strategy gives the caller interchangeable ways of doing the same job right now, while Command, further down this list, packages one operation with its arguments so the work can run later or somewhere else.