Python's generics system brings type safety to dynamic code, enabling reusable functions and classes that work across types while aiding static analysis tools like mypy. Introduced in Python 3.5 through PEP 483 and refined in versions like 3.12, generics use type variables without runtime overhead, leveraging duck typing for flexibility.

What Are Generics?

Generics parameterize types, allowing structures like lists or custom classes to specify element types at usage time. Core building block: TypeVar from typing (built-in since 3.12). They exist purely for static checking—no enforcement at runtime, unlike Java's generics.

from typing import TypeVar
T = TypeVar('T')  # Placeholder for any type

Generic Functions in Action

Create flexible utilities by annotating parameters and returns with type variables. A practical example is a universal adder for any comparable types.

from typing import TypeVar

T = TypeVar('T')  # Any type supporting +

def add(a: T, b: T) -> T:
    return a + b

# Usage
result1: int = add(5, 3)           # Returns 8, type int
result2: str = add("hello", "world")  # Returns "helloworld", type str
result3: float = add(2.5, 1.7)     # Returns 4.2, type float

Mypy infers and enforces matching types—add(1, "a") fails checking. Another example: identity function.

def identity(value: T) -> T:
    return value

This works seamlessly across any type.

Building Generic Classes

Inherit from Generic[T] for type-aware containers (or use class Stack[T]: in 3.12+). A real-world Result type handles success/error cases like Rust's Result<T, E>.

from typing import Generic, TypeVar

T = TypeVar('T')  # Success type
E = TypeVar('E')  # Error type

class Result(Generic[T, E]):
    def __init__(self, value: T | None = None, error: E | None = None):
        self.value = value
        self.error = error
        self.is_ok = error is None

    def unwrap(self) -> T | None:
        if self.is_ok:
            return self.value
        raise ValueError(f"Error: {self.error}")

class Stack(Generic[T]):
    def __init__(self) -> None:
        self.items: list[T] = []

    def push(self, item: T) -> None:
        self.items.append(item)

    def pop(self) -> T:
        return self.items.pop()

Sample Usage:

# Result usage
def divide(a: float, b: float) -> Result[float, str]:
    if b == 0:
        return Result(error="Division by zero")
    return Result(value=a / b)

success = divide(10, 2)
print(success.unwrap())  # 5.0

failure = divide(10, 0)
# failure.unwrap() #raises ValueError

# Stack usage
int_stack: Stack[int] = Stack()
int_stack.push(1)
int_stack.push(42)
print(int_stack.pop())  # 42

str_stack: Stack[str] = Stack()
str_stack.push("hello")
print(str_stack.pop())  # "hello"

Advanced Features

• Multiple TypeVars: K = TypeVar('K'); V = TypeVar('V') for dict-like classes: class Mapping(Generic[K, V]):.
• Bounds: T = TypeVar('T', bound=str) restricts to subclasses of str.
• Variance: TypeVar('T', contravariant=True) for input-only types.

Mypy in Practice

Save the Stack class to stack.py. Run mypy stack.py—no errors for valid code.

Test errors: Add stack: Stack[int] = Stack[str]() then mypy stack.py:

stack.py: error: Incompatible types in assignment (expression has type "Stack[str]", variable has type "Stack[int]")  [assignment]

Fix by matching types. Correct usage passes silently.

Practical Benefits and Tools

Generics catch errors early in IDEs and CI pipelines. Run mypy script.py to validate. No performance hit—type hints erase at runtime. Ideal for libraries like FastAPI or Pydantic.

Python dataclasses, introduced in Python 3.7 via the dataclasses module, streamline class definitions for data-heavy objects by auto-generating boilerplate methods like __init__, __repr__, __eq__, and more. They promote cleaner code, type safety, and IDE integration without sacrificing flexibility. This article covers basics to advanced usage, drawing from official docs and practical patterns.python

Defining a Dataclass

Start by importing and decorating a class with @dataclass. Fields require type annotations; the decorator handles the rest.

from dataclasses import dataclass

@dataclass
class Point:
    x: float
    y: float

p = Point(1.5, 2.5)
print(p)  # Point(x=1.5, y=2.5)

Customization via parameters: @dataclass(eq=True, order=False, frozen=False, slots=False) toggles comparisons, immutability (frozen=True prevents attribute changes), and memory-efficient slots (Python 3.10+).

Field Defaults and Customization

Use assignment for immutables; field(default_factory=...) for mutables to avoid shared state.

from dataclasses import dataclass, field

@dataclass
class Employee:
    name: str
    dept: str = "Engineering"
    skills: list[str] = field(default_factory=list)
    id: int = field(init=False, default=0)  # Skipped in __init__, set later

Post-init logic: Define __post_init__ for validation or computed fields.

def __post_init__(self):
    self.id = hash(self.name)

Other field() options: repr=False, compare=False, hash=None, metadata={...} for extras, kw_only=True (3.10+) for keyword-only args.

Inheritance and Composition

Dataclasses support single/multiple inheritance; parent fields prepend in __init__.

@dataclass
class Employee(Person):  # Assuming Person from earlier
    salary: float

Nested dataclasses work seamlessly; use InitVar for init-only vars.

from dataclasses import dataclass, InitVar

@dataclass
class Logger:
    name: str
    level: str = "INFO"
    log_file: str = None  # Computed during init

    config: InitVar[dict] = None

    def __post_init__(self, config):
        if config:
            self.level = config.get('default_level', self.level)
            self.log_file = config.get('log_path', f"{self.name}.log")
        else:
            self.log_file = f"{self.name}.log"

app_config = {'default_level': 'DEBUG', 'log_path': '/var/logs/app.log'}
logger = Logger("web_server", config=app_config)
print(logger)  # Logger(name='web_server', level='DEBUG', log_file='/var/logs/app.log')
logger = Logger("web_server")
print(logger)  # Logger(name='web_server', level='INFO', log_file='web_server.log')

Field order via __dataclass_fields__ aids debugging.

Utilities and Patterns

• replace(): Immutable updates: new_p = replace(p, age=31).
• Exports: asdict(p), astuple(p) for serialization.
• Introspection: fields(p), is_dataclass(p), make_dataclass(...).

Best Practices and Gotchas

Prefer dataclasses over namedtuples for mutability needs; use frozen=True for hashable configs. Avoid overriding generated methods unless necessary—extend via __post_init__. For production, validate inputs and consider slots=True for perf gains.

Python decorators represent one of the language's most elegant patterns for extending function behavior without touching their source code. At their core lies a fundamental concept—closures—that enables this magic. This article explores their intimate relationship, including decorators that handle their own arguments.

Understanding Closures First

A closure is a nested function that "closes over" (captures) variables from its outer scope, retaining access to them even after the outer function returns. This memory capability is what makes closures powerful.

def make_multiplier(factor):
    def multiply(number):
        return number * factor  # Remembers 'factor'
    return multiply

times_three = make_multiplier(3)
print(times_three(5))  # Output: 15

Here, multiply forms a closure over factor, preserving its value across calls.

The Basic Decorator Pattern

Decorators leverage closures by returning wrapper functions that remember the original function:

from functools import wraps

def simple_decorator(func):
    @wraps(func)
    def wrapper():
        print("Before the function runs")
        func()
        print("After the function runs")
    return wrapper

@simple_decorator
def greet():
    print("Hello!")

greet()

The @simple_decorator syntax assigns wrapper (a closure remembering func) to greet. When called, wrapper executes extra logic around the original.

The @wraps Decorator Explained

The @wraps(func) from functools copies the original function's __name__, __doc__, and other metadata to the wrapper. Without it:

print(greet.__name__)  # 'wrapper' ❌

With @wraps(func):

print(greet.__name__)  # 'greet' ✅
help(greet)            # Shows correct docstring

This makes decorators transparent to help(), inspect, and IDEs—essential for production code.

Decorators That Accept Arguments

Real-world decorators often need configuration. This requires a three-layer structure: a decorator factory, the actual decorator, and the innermost wrapper—all powered by closures.

from functools import wraps

def repeat(times):
    """Decorator factory that returns a decorator."""
    def decorator(func):
        @wraps(func)
        def wrapper(*args, **kwargs):
            for _ in range(times):
                result = func(*args, **kwargs)
            return result
        return wrapper  # Closure over 'times' and 'func'
    return decorator

@repeat(3)
def greet(name):
    print(f"Hello, {name}!")

greet("Alice")
# Output:
# Hello, Alice!
# Hello, Alice!
# Hello, Alice!

How it flows:

1. @repeat(3) calls repeat(3), returning decorator.
2. decorator(greet) returns wrapper.
3. wrapper closes over both times=3 and func=greet, passing through *args/**kwargs.

This nested closure structure handles decorator arguments while preserving the original function's flexibility.

Why This Relationship Powers Python

Closures give decorators their statefulness—remembering configuration (times) and the target function (func) across calls. Common applications include:

• Timing: Measure execution duration.
• Caching: Store results with lru_cache.
• Authorization: Validate access before execution.
• Logging: Track function usage.

Mastering closures unlocks decorators as composable tools, making your code cleaner and more expressive. The @ syntax is just syntactic sugar; closures provide the underlying mechanism.