The Architecture of Pythonic Systems

1. The GoF Fallacy: When Classic Patterns Collide with the Python Data Model

In 1994, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides published Design Patterns: Elements of Reusable Object-Oriented Software. The "Gang of Four" (GoF) catalog became the foundational canon of enterprise software engineering. For thirty years, programmers have memorized its twenty-three patterns—Factory Method, Abstract Factory, Strategy, Command, Observer, Decorator, Singleton—as universal truths of system design.

Yet when software engineers attempt to translate the GoF catalog directly into Python, an unsettling pathology emerges. Systems develop five-level-deep class hierarchies, abstract base classes that do nothing but pass arguments to other abstract base classes, factories that instantiate factories, and verbose visitor traversals that fight the interpreter at every step. Codebases balloon in surface area while losing the very concision, dynamism, and ergonomic clarity that made Python compelling in the first place.

This failure is not a flaw in the engineer, nor is it an inherent limitation of Python. It is an epistemic mismatch: the Gang of Four patterns were not universal laws of computation; they were structural workarounds for the limitations of static, nominal, single-dispatch languages without first-class functions or expressive metaprogramming (specifically C++ and early Smalltalk).

Consider how the Python runtime natively dissolves classic GoF patterns:

• Strategy: In C++ or Java, Strategy requires a StrategyInterface, a ConcreteStrategyA, a ConcreteStrategyB, and a Context class with a pointer. In Python, a strategy is simply a callable—a plain function, lambda, or closure passed as a first-class argument: sorted(data, key=lambda x: x.score).
• Command: Rather than allocating an abstract Command class with an execute() method and state encapsulation, Python leverages closures, generator functions, or any object implementing the __call__ protocol.
• Iterator: The entire Iterator pattern is embedded into the core language syntax via the __iter__ and __next__ dunder protocol and the yield keyword, managed automatically by for loops and generator comprehensions.
• Singleton: Implementing a thread-safe Singleton class with double-checked locking in Python via __new__ is an explicit anti-pattern. A Python module is already an execution-guaranteed, thread-safe, lazily initialized singleton cached in sys.modules.
• Decorator: The GoF Decorator pattern (wrapping an object inside another object with the same interface to add behavior) is replaced by native decorator syntax (@decorator), which operates on functions, coroutines, and classes via higher-order functions.

Does this mean design patterns do not exist in Python? Far from it. As Python matured from a scripting utility into the world's most dominant language for distributed backend services, cloud infrastructure, and the entire ecosystem of Artificial Intelligence, a new, battle-tested architectural lexicon crystallized.

These modern Pythonic design patterns divide into two distinct fronts:

1. General Software Architecture: Patterns for clean interfaces, dependency inversion, plugin extensibility, and resource orchestration, seen in flagship frameworks like FastAPI, SQLAlchemy, Pydantic, Celery, and Starlette.
2. Data Science & Machine Learning Architecture: Specialized structural patterns built for array processing, numerical pipelines, dynamic computation graphs, hardware kernel dispatch, and foundation model adaptation, powering PyTorch, Scikit-Learn, Polars, Hugging Face Transformers, and vLLM.

2. Protocol-Driven Structural Subtyping: Compile-Time Duck Typing

For decades, Python relied on dynamic "duck typing" at runtime: if it walks like a duck and quacks like a duck, it's a duck. While expressive, runtime duck typing offered zero compile-time safety. An unhandled AttributeError would only detonate inside a high-throughput production worker three hours after deployment.

To address this, developers historically turned to Abstract Base Classes (ABCs) via abc.ABCMeta. But ABCs introduce nominal subtyping: class $B$ is only accepted as an implementation of interface $A$ if $B$ explicitly inherits from $A$ in its class definition header (class B(A):). This breaks modularity. If you write a library, you cannot use an ABC defined in an unrelated third-party library without creating an explicit dependency or writing artificial adapter classes.

The modern Pythonic pattern is Structural Subtyping via typing.Protocol (PEP 544). Protocols enable static type-checkers (Mypy, Pyright, Ruff) to verify that an object satisfies an interface solely by inspecting its public method and attribute signatures, with zero inheritance required.

from typing import Protocol, runtime_checkable, Any
from dataclasses import dataclass

@dataclass(frozen=True)
class TelemetryEvent:
    name: str
    payload: dict[str, Any]
    timestamp_ns: int

@runtime_checkable
class EventSink(Protocol):
    """Structural interface for any telemetry emission backend."""
    def emit(self, event: TelemetryEvent) -> bool: ...
    def flush(self, timeout_seconds: float = 5.0) -> None: ...

# Third-party or decoupled implementation (Zero inheritance from EventSink!)
class ClickHouseTelemetryBuffer:
    """Uncoupled class satisfying the protocol purely through shape."""
    def __init__(self, cluster_url: str):
        self.cluster_url = cluster_url
        self._buffer: list[TelemetryEvent] = []

    def emit(self, event: TelemetryEvent) -> bool:
        self._buffer.append(event)
        return True

    def flush(self, timeout_seconds: float = 5.0) -> None:
        # Batch write to ClickHouse endpoint
        self._buffer.clear()

def record_metric(sink: EventSink, event: TelemetryEvent) -> None:
    # Static type checkers verify this at lint time;
    # @runtime_checkable allows safe runtime defensive checks if needed.
    if isinstance(sink, EventSink):
        sink.emit(event)

By decorating with @runtime_checkable, you gain both worlds: strict static type-checking during continuous integration and the ability to call isinstance(obj, EventSink) at runtime for defensive validation, all while preserving zero-dependency decoupling between caller and consumer.

3. The Dynamic Registry Pattern & Inversion of Control

A perennial failure mode in growing codebases is the "spaghetti dispatch" anti-pattern: sprawling if/elif/else or match/case blocks hardcoding references to every concrete implementation:

# Brittle: adding a parser requires modifying this central router file!
def get_parser(file_format: str):
    if file_format == "parquet":
        from parsers.parquet import ParquetParser
        return ParquetParser()
    elif file_format == "avro":
        from parsers.avro import AvroParser
        return AvroParser()
    # Repeat 30 times...

This violates the Open/Closed Principle: every new format forces mutations to existing core routing files, generating merge conflicts and circular imports.

The Pythonic remedy is the Decorator-Driven Registry Pattern. The registry acts as a thread-safe, typed catalog. Concrete handlers register themselves at module-import time by decorating their class or function definition. The core engine knows nothing about specific implementations; it simply looks up keys in the catalog.

from typing import Callable, TypeVar, dict
import threading

T = TypeVar("T")

class Registry:
    """Thread-safe, typed extensible plugin and handler registry."""
    def __init__(self, name: str):
        self.name = name
        self._registry: dict[str, type] = {}
        self._lock = threading.Lock()

    def register(self, key: str) -> Callable[[type[T]], type[T]]:
        def decorator(cls: type[T]) -> type[T]:
            with self._lock:
                if key in self._registry:
                    raise ValueError(f"Key '{key}' already registered in {self.name}")
                self._registry[key] = cls
            return cls
        return decorator

    def get(self, key: str, **kwargs) -> Any:
        with self._lock:
            target_cls = self._registry.get(key)
        if target_cls is None:
            raise KeyError(f"Unknown backend '{key}' in registry {self.name}. "
                           f"Available: {list(self._registry.keys())}")
        return target_cls(**kwargs)

# Global domain registry instance
PARSER_REGISTRY = Registry("DataParsers")

# Extensibility: defined in independent modules without modifying core code
@PARSER_REGISTRY.register("arrow_ipc")
class ArrowStreamParser:
    def __init__(self, batch_size: int = 65536):
        self.batch_size = batch_size

    def parse(self, stream_bytes: bytes):
        return f"Parsing Arrow stream with batch size {self.batch_size}"

4. The Descriptor Protocol & Field Orchestration

In Java or C#, cross-cutting attribute concerns—such as database field mapping, lazy evaluation, dirty tracking, validation, or type casting—are often implemented via runtime reflection, bytecode manipulation, or endless boilerplate getters and setters.

Python solves this natively at the language core through the Descriptor Protocol. A descriptor is any object that implements at least one of __get__, __set__, or __delete__. Whenever an attribute on an instance is accessed (instance.field), Python's internal attribute resolution mechanism (object.__getattribute__) intercepts the lookup and delegates control to the descriptor's __get__ method.

With Python 3.6+ and PEP 487 (__set_name__ and __init_subclass__), descriptors became clean, transparent, and completely free of the arcane metaclass gymnastics that previously terrified developers.

from typing import Any, dict

class ValidatedBoundedNumber:
    """Descriptor that enforces range bounds and tracks attribute mutation."""
    def __init__(self, min_val: float, max_val: float):
        self.min_val = min_val
        self.max_val = max_val
        self.storage_name: str = ""

    def __set_name__(self, owner: type, name: str) -> None:
        # PEP 487: Automatically captures attribute variable name at class creation!
        self.storage_name = f"_field_{name}"

    def __get__(self, instance: Any, owner: type) -> Any:
        if instance is None:
            return self # Accessed via class namespace: Hyperparameters.learning_rate
        return getattr(instance, self.storage_name, None)

    def __set__(self, instance: Any, value: float) -> None:
        if not (self.min_val <= value <= self.max_val):
            raise ValueError(
                f"Value {value} for {self.storage_name[7:]} violates range "
                f"[{self.min_val}, {self.max_val}]"
            )
        setattr(instance, self.storage_name, value)

class TrainingConfig:
    # Declarative field specification without writing repetitive boilerplate
    learning_rate = ValidatedBoundedNumber(min_val=1e-7, max_val=1.0)
    dropout = ValidatedBoundedNumber(min_val=0.0, max_val=0.99)

    def __init__(self, lr: float, dropout: float):
        self.learning_rate = lr
        self.dropout = dropout

5. Inversion of Control via Generator-Yield Contexts

Classical Dependency Injection (DI) frameworks in enterprise software (like Spring in Java or Guice) rely heavily on reflection, XML configs, and complicated service containers.

In modern Python, Dependency Injection converged on an exquisitely simple, readable idiom: Generator functions as scoped lifecycle providers. A generator function yields a managed resource (a database connection, an HTTP client session, a transaction span). Everything prior to the yield constitutes the setup phase; everything after the yield constitutes the teardown phase.

from typing import AsyncGenerator, Annotated
from contextlib import asynccontextmanager

class DatabaseSession:
    async def commit(self): ...
    async def rollback(self): ...
    async def close(self): ...

async def get_db_transaction() -> AsyncGenerator[DatabaseSession, None]:
    """Lifecycle-managed dependency: setup -> yield -> teardown."""
    session = DatabaseSession()
    try:
        yield session
        await session.commit()
    except Exception:
        await session.rollback()
        raise
    finally:
        await session.close()

# Minimal demonstration of resolving a dependency DAG:
async def execute_scoped_operation(route_handler):
    gen = get_db_transaction()
    session = await anext(gen) # Execute setup until yield
    try:
        result = await route_handler(session)
        try:
            await anext(gen) # Run teardown commit
        except StopAsyncIteration:
            pass
        return result
    except Exception as err:
        await gen.athrow(err) # Trigger exception handler and rollback

6. Asynchronous Middleware Pipelines: The Onion Architecture

In distributed web services, cross-cutting concerns—rate limiting, authorization tokens, OpenTelemetry distributed tracing spans, distributed locks, and response compression—must wrap request handling in discrete layers.

The Pythonic architecture for this is the Onion Pipeline (Chain of Responsibility), standardized across modern ASGI applications in Starlette and Django. Each middleware is a callable that receives the request and a reference to the next handler in the stack (call_next).

import time
from typing import Callable, Awaitable
from starlette.requests import Request
from starlette.responses import Response
from starlette.middleware.base import BaseHTTPMiddleware

class TelemetryOnionMiddleware(BaseHTTPMiddleware):
    async def dispatch(
        self, request: Request, call_next: Callable[[Request], Awaitable[Response]]
    ) -> Response:
        start_time = time.perf_counter_ns()
        request_id = request.headers.get("X-Request-ID", "anon")

        try:
            # Forward down the stack to inner layers:
            response = await call_next(request)
        except Exception as exc:
            duration_ms = (time.perf_counter_ns() - start_time) / 1_000_000
            print(f"[ERR] Req {request_id} crashed after {duration_ms:.2f}ms: {exc}")
            raise

        duration_ms = (time.perf_counter_ns() - start_time) / 1_000_000
        response.headers["X-Process-Time-Ms"] = f"{duration_ms:.2f}"
        return response

7. The Machine Learning Imperative: Why DS/ML Demands Distinct Patterns

The design patterns of general software engineering were designed for web requests, databases, and microservices: systems characterized by I/O-bound operations, network latencies, transactional ACID guarantees, and discrete JSON payloads.

When Python expanded to swallow the entire world of Data Science and Machine Learning, it entered a completely different physical universe governed by unique computational constraints:

• Massive Continuous Tensors: Operations are not performed on single objects, but on dense multidimensional arrays containing millions or billions of floating-point numbers ($N \times D$ matrices). Memory allocations and cache misses dominate execution time.
• Hardware Acceleration & Fused Kernels: Execution does not take place on the CPU; it is offloaded across PCIe buses to GPU streaming multiprocessors (SMs) running CUDA, Triton, or ROCm kernels. Python acts purely as an orchestrator for compiled C++/CUDA engines.
• Stochastic State & Convergence: Systems are not deterministic business rules; they optimize non-convex loss surfaces via backpropagation and floating-point gradient updates.
• Catastrophic Data Leakage: In traditional software, passing global configuration to a service is standard practice. In machine learning, allowing a preprocessing step (like a scaler or imputation mean) to see test-set statistics constitutes data leakage, invalidating scientific findings and causing catastrophic failure in production.

To survive these constraints, the machine learning community invented its own sophisticated design pattern architecture.

8. The Estimator & Transformer Pipeline Protocol

The single most successful software design pattern in the history of data science is the Scikit-Learn Estimator and Transformer Protocol. Formulated in the early 2010s, it unified hundreds of disparate statistical algorithms into a single composable interface.

The pattern enforces four invariant rules:

1. Hyperparameter Isolation in __init__: An estimator's __init__ method must take only explicit hyperparameters as keyword arguments with default values. It must never touch actual data, calculate statistics, or create internal state.
2. The fit(X, y) Contract: All state estimation from data occurs strictly inside fit. Any parameter learned from data (e.g., means, standard deviations, feature importances, tree split points) must be stored on the instance with a trailing underscore (e.g., self.mean_, self.scale_).
3. The transform(X) or predict(X) Contract: Preprocessors implement transform(X), taking raw data and returning mapped data using exclusively the previously learned self.param_ parameters without mutating internal state. Predictors implement predict(X).
4. Pipeline Composability: Because transformers share the exact same signature, they can be chained into a Pipeline([('scaler', StandardScaler()), ('model', Ridge())]). When cross_val_score(pipeline, X, y, cv=5) executes, the pipeline guarantees that the scaler is fitted only on the 4 training folds and applied to the 5th validation fold without leaking data.

import numpy as np
import pandas as pd
from sklearn.base import BaseEstimator, TransformerMixin
from sklearn.utils.validation import check_is_fitted

class EmpiricalBayesTargetEncoder(BaseEstimator, TransformerMixin):
    """
    Scikit-learn compliant transformer implementing smoothed target encoding.
    Adheres strictly to the Estimator-Transformer invariant.
    """
    def __init__(self, smoothing_weight: float = 10.0):
        # Rule 1: Only store hyperparams! No data inspection here.
        self.smoothing_weight = smoothing_weight

    def fit(self, X: pd.DataFrame, y: pd.Series):
        # Rule 2: Learn parameters from training fold only; store with trailing underscore
        y_vec = np.asarray(y)
        self.global_mean_ = float(np.mean(y_vec))
        self.encodings_: dict[str, dict[Any, float]] = {}

        for col in X.columns:
            stats = pd.DataFrame({'cat': X[col], 'target': y_vec}).groupby('cat')['target'].agg(['count', 'mean'])
            # Empirical Bayes smoothing formula
            counts = stats['count']
            means = stats['mean']
            smoothed = (counts * means + self.smoothing_weight * self.global_mean_) / (counts + self.smoothing_weight)
            self.encodings_[col] = smoothed.to_dict()

        return self # Method chaining convention

    def transform(self, X: pd.DataFrame) -> pd.DataFrame:
        # Rule 3: Apply learned encodings statelessly; handle unseen categories with global_mean_
        check_is_fitted(self, attributes=['global_mean_', 'encodings_'])
        X_out = X.copy()
        for col in X.columns:
            mapping = self.encodings_.get(col, {})
            X_out[col] = X_out[col].map(mapping).fillna(self.global_mean_)
        return X_out

9. Composite Modules & Dynamic Forward/Backward Hooks

In deep learning frameworks, neural networks are recursive composite trees. A modern Transformer model is a Module containing a list of TransformerBlock submodules, each containing an Attention and FeedForward submodule, each containing Linear and LayerNorm submodules.

PyTorch's torch.nn.Module implements the Composite Pattern: calling model.to('cuda'), model.eval(), or model.parameters() recursively walks the entire tree of submodules without requiring manual traversal code.

However, this creates a major architectural challenge: how do you inspect intermediate activation tensors, extract features, clip gradients, or inject parameter-efficient adaptations (like LoRA) into a complex pretrained model without modifying its original source code or subclassing deeply nested classes?

The solution is the Hook Pattern (Observer & Interceptor). PyTorch allows developers to attach callables via:

• register_forward_pre_hook: intercepts and optionally mutates inputs before a submodule's forward() runs.
• register_forward_hook: intercepts and records or alters the output activations of any layer.
• register_full_backward_hook: intercepts and manipulates incoming and outgoing gradient tensors during reverse-mode automatic differentiation.

import torch
import torch.nn as nn

class LoRALinearWrapper(nn.Module):
    """
    Composite adapter decorating an existing nn.Linear layer.
    Injects low-rank trainable bypass without mutating original weights.
    """
    def __init__(self, base_layer: nn.Linear, rank: int = 8, alpha: float = 16.0):
        super().__init__()
        self.base_layer = base_layer
        self.base_layer.weight.requires_grad = False # Freeze foundational weights
        if self.base_layer.bias is not None:
            self.base_layer.bias.requires_grad = False

        self.rank = rank
        self.scaling = alpha / rank

        # Low-rank matrices: A initializes with Gaussian noise, B with zeros
        self.lora_A = nn.Parameter(torch.randn(rank, base_layer.in_features) * 0.01)
        self.lora_B = nn.Parameter(torch.zeros(base_layer.out_features, rank))

    def forward(self, x: torch.Tensor) -> torch.Tensor:
        # Base path (frozen, evaluated in fp16/bf16 or int8)
        base_out = self.base_layer(x)
        # Low-rank adapter path: x @ A^T @ B^T * scaling
        adapter_out = (x @ self.lora_A.t() @ self.lora_B.t()) * self.scaling
        return base_out + adapter_out

# Non-invasive Feature Extraction via Forward Hooks:
def attach_activation_cache(model: nn.Module, target_layer_name: str) -> dict:
    cache = {}
    for name, module in model.named_modules():
        if name == target_layer_name:
            def hook_fn(mod, inputs, outputs):
                cache['activations'] = outputs.detach().cpu()
            module.register_forward_hook(hook_fn)
            break
    return cache

10. Lazy Expression Graphs & Deferred Execution

In traditional data analysis with standard Pandas, execution is eager. If you write:

# Materializes full 20GB dataset into memory, filters, then materializes again!
df = pd.read_parquet("s3://warehouse/telemetry_100m_rows.parquet")
filtered = df[df["country"] == "US"]
result = filtered[["user_id", "session_length"]].groupby("user_id").mean()

Every intermediate step allocates a new in-memory DataFrame. If your dataset is 40 gigabytes and your workstation has 32 gigabytes of RAM, the process triggers an Out-Of-Memory (OOM) kernel crash.

The modern high-performance pattern for data processing is the Lazy Expression Graph (Deferred Execution DAG). Rather than executing computations immediately, API calls build an abstract syntax tree of operations (a logical query plan). Physical execution only occurs when a terminal action (such as .collect()) is invoked.

import polars as pl

# Builds a logical plan without reading the file into RAM
lazy_query = (
    pl.scan_parquet("telemetry_100m_rows.parquet")
    .filter(pl.col("country") == "US")
    .group_by("user_id")
    .agg(pl.col("session_length").mean().alias("avg_session"))
    .sort("avg_session", descending=True)
)

# Inspect the optimized physical execution plan
print(lazy_query.explain())

# Execute streaming with minimal memory footprint
df_result = lazy_query.collect(streaming=True)

11. Hardware-Aware Strategy & Pluggable Backend Dispatch

In deep learning deployment and high-throughput LLM inference, algorithms cannot rely on uniform hardware. An attention layer executing on an NVIDIA H100 (Hopper architecture, SM 9.0) should run FlashAttention-3 with Tensor Core FP8 asynchronous memory copies. The same layer on an older A100 (Ampere, SM 8.0) must run FlashAttention-2. On an Apple Silicon Mac, it must dispatch to Metal Performance Shaders (MPS); on a CPU server, it must fall back to AVX-512 SIMD vectorization.

Hardcoding hardware branches inside neural layer code creates unmaintainable chaos. The design pattern used by top inference engines like vLLM and PyTorch SDPA is Hardware-Aware Strategy Dispatch.

import torch
from typing import Callable

class AttentionBackendDispatcher:
    """Hardware-aware Strategy Dispatcher selecting optimal kernel backend."""
    def __init__(self):
        self._strategy: Callable = self._resolve_optimal_backend()

    def _resolve_optimal_backend(self) -> Callable:
        if torch.cuda.is_available():
            major, minor = torch.cuda.get_device_capability()
            if major >= 8:
                print(f"Dispatching to FlashAttention-2 (CUDA SM {major}.{minor})")
                return self._flash_attention_kernel
            else:
                print("Dispatching to Cutlass Memory-Efficient Attention")
                return self._memory_efficient_kernel
        print("Dispatching to CPU Math Attention")
        return self._math_fallback_kernel

    def _flash_attention_kernel(self, q, k, v, scale):
        with torch.backends.cuda.sdp_kernel(enable_flash=True, enable_math=False):
            return torch.nn.functional.scaled_dot_product_attention(q, k, v, scale_factor=scale)

    def _memory_efficient_kernel(self, q, k, v, scale):
        with torch.backends.cuda.sdp_kernel(enable_mem_efficient=True, enable_math=False):
            return torch.nn.functional.scaled_dot_product_attention(q, k, v, scale_factor=scale)

    def _math_fallback_kernel(self, q, k, v, scale):
        with torch.backends.cuda.sdp_kernel(enable_flash=False, enable_math=True):
            return torch.nn.functional.scaled_dot_product_attention(q, k, v, scale_factor=scale)

    def __call__(self, q: torch.Tensor, k: torch.Tensor, v: torch.Tensor, scale: float = 0.125):
        return self._strategy(q, k, v, scale)

12. Foundation Backbone, Task Heads & Parameter Decoupling

In contemporary deep learning, training models from scratch is economically prohibitive. A frontier multimodal foundation model costs millions of dollars in compute.

To deploy foundation models across dozens of disparate production tasks (document classification, sentiment analysis, extractive QA, next-token generation), production systems utilize the Backbone-Head Decoupling Pattern.

The architecture cleanly separates two concerns:

• The Invariant Backbone: The foundational feature extractor (e.g., LlamaModel, ViTModel, ResNetBackbone). Its sole responsibility is transforming raw high-dimensional tokens or pixels into dense, semantically rich contextual latent embeddings $\mathbf{Z} \in \mathbb{R}^{B \times L \times D}$.
• The Modular Task Head: A lightweight output projection layer (e.g., a classification projection $\mathbb{R}^{D \to K}$, a language modeling head $\mathbb{R}^{D \to V_{\text{vocab}}}$, or a bounding box regression head $\mathbb{R}^{D \to 4}$).

import torch
import torch.nn as nn

class TransformerBackbone(nn.Module):
    """Invariant representation learner: extracts d-dimensional contextual latents."""
    def __init__(self, hidden_dim: int = 768):
        super().__init__()
        self.hidden_dim = hidden_dim
        self.layers = nn.ModuleList([nn.Linear(hidden_dim, hidden_dim) for _ in range(4)])

    def forward(self, x: torch.Tensor) -> torch.Tensor:
        for layer in self.layers:
            x = torch.relu(layer(x))
        return x # Shape: [Batch, SeqLen, HiddenDim]

class SequenceClassifierHead(nn.Module):
    """Task-specific head projecting latents to class logits."""
    def __init__(self, hidden_dim: int, num_classes: int):
        super().__init__()
        self.classifier = nn.Linear(hidden_dim, num_classes)

    def forward(self, latents: torch.Tensor) -> torch.Tensor:
        # Pool over sequence length: [Batch, HiddenDim]
        pooled = latents.mean(dim=1)
        return self.classifier(pooled)

class CompositeModel(nn.Module):
    """Composes the invariant backbone with any swappable downstream head."""
    def __init__(self, backbone: TransformerBackbone, head: nn.Module):
        super().__init__()
        self.backbone = backbone
        self.head = head

    def forward(self, x: torch.Tensor) -> torch.Tensor:
        latents = self.backbone(x)
        return self.head(latents)

13. The Anti-Pattern Taxonomy: Unpythonic Traps to Avoid

Architectural mastery requires not only knowing which patterns to apply, but recognizing the common traps that degrade Python systems. Here are the five most prevalent "unpythonic" anti-patterns in production codebases:

# UNPYTHONIC: Over-abstracted single-method class
class CustomerEmailSender:
    def __init__(self, client):
        self.client = client
    def execute(self, email: str):
        self.client.send(email)

# PYTHONIC: A closure or simple partial function
def make_email_sender(client):
    def send_email(email: str):
        client.send(email)
    return send_email

14. The Architectural Matrix: Classical vs. Pythonic Patterns

The table below synthesizes the structural evolution from classical Gang of Four object-oriented patterns to modern, production-grade Pythonic paradigms across general software and machine learning systems: