Setting Memory Limits

If the Linux OOM killer terminates the process, Memray cannot write its profile data to disk, and the capture is lost.

We can avoid this by setting a soft memory limit using Python’s built-in resource module. This forces the interpreter to raise a MemoryError before the OS terminates the process, allowing Memray to save the profile data.

A Memory Leak Example

Below is an example script that triggers an OOM using either a Python bytes object or a NumPy array.

import os
import resource
import secrets
import numpy as np

def limit_memory(max_bytes: int) -> None:
    """Set a virtual memory limit to trigger a Python MemoryError before OS SIGKILL."""
1    resource.setrlimit(resource.RLIMIT_AS, (max_bytes, max_bytes))

def leak_python() -> None:
    """Trigger an OOM error by allocating progressively larger Python bytes objects."""
    print("Triggering OOM with a single pure Python bytes object...")
    current_size = 10 * 1024 * 1024  # Start at 10 MB
    data = None

    while True:
        if data is not None:
1            del data  # Explicitly free memory before the next allocation

        print(f"Attempting to allocate {current_size // (1024**2)} MB bytes object...")
2        data = os.urandom(current_size)
3        current_size = int(current_size * 1.5)

def leak_numpy() -> None:
    """Trigger an OOM error by allocating progressively larger NumPy float64 arrays."""
    print("Triggering OOM with a single native NumPy array...")
    current_elements = (10 * 1024 * 1024) // 8  # 8 bytes per float64
    arr = None

    while True:
        if arr is not None:
            del arr  # Explicitly free memory before the next allocation

        mb_size = (current_elements * 8) // (1024**2)
        print(f"Attempting to allocate {mb_size} MB float64 array...")

        # This single C-level malloc will eventually fail and raise MemoryError
1        arr = np.ones(current_elements, dtype=np.float64)
2        current_elements = int(current_elements * 1.5)

if __name__ == "__main__":
1    limit_memory(1 * 1024**3)

    try:
        if secrets.choice([True, False]):
            leak_python()
        else:
            leak_numpy()
2    except MemoryError:
        print("\n[!] MemoryError caught. Memray can now flush the capture file to disk.")

Running the Profiler

To capture native allocations, run the script with the --native flag:

memray run --native oom_simulator.py

This generates a binary capture file (e.g., memray-oom_simulator.py.12345.bin).

Analyzing the Results

Memray provides several formats to analyze the generated binary file.

memray flamegraph memray-oom_simulator.py.12345.bin

memray run --native --live oom_simulator.py

memray stats memray-oom_simulator.py.12345.bin

memray tree memray-oom_simulator.py.12345.bin

1. Loading Financial Data

import polars as pl
import polars.selectors as cs
from pathlib import Path
import os

1root = Path(os.path.abspath("")).parent.parent

2df = pl.read_ipc(root / "assets" / "data" / "ticker_data.arrow")
3df = df.sort(["ticker", "date"])

df.head(5)

2. Expressions: The Atomic Units of Logic

Expressions are reusable, composable chunks of logic. Define once, apply anywhere.

1log_return = (pl.col("close") / pl.col("close").shift(1)).log().over("ticker")

realized_vol = (log_return.rolling_std(window_size=21) * (252**0.5)).over(
    "ticker"
2)


def min_max_scale(name: str) -> pl.Expr:
    col = pl.col(name)
3    return (col - col.min()) / (col.max() - col.min())

3. Context: Selection & Feature Engineering

with_columns adds multiple indicators in a single pass.

df = df.with_columns(
1    ret=log_return,
    vol=realized_vol,
2    typical_price=(pl.col("high") + pl.col("low") + pl.col("close")) / 3,
)

df.tail(5)

4. Context: Aggregation (group_by)

risk_summary = df.group_by("ticker").agg(
    annual_return=(pl.col("ret").mean() * 252),
    annual_vol=(pl.col("ret").std() * (252**0.5)),
1    max_drawdown=((pl.col("close") / pl.col("close").cum_max() - 1).min()),
2    sharpe_ratio=(pl.col("ret").mean() / pl.col("ret").std()) * (252**0.5),
)

risk_summary.sort("sharpe_ratio", descending=True).head(5)

5. Power Selectors (polars.selectors)

Target columns by properties instead of hardcoding names — handy for scenario shocks.

1price_shock = cs.starts_with("open", "high", "low", "close") * 1.01

df.select(
    "date",
    "ticker",
2    price_shock.name.suffix("_shock"),
).head(3)

6. Window Functions (over)

Compute group-level stats and project them back onto individual rows — no merge needed.

df.with_columns(
    vol_z=(pl.col("volume") - pl.col("volume").mean().over("ticker"))
1    / pl.col("volume").std().over("ticker"),
2    rel_strength=pl.col("close") / pl.col("close").mean().over("date"),
).head(5)

7. Time Series: Rolling Metrics & Asof Joins

df.with_columns(
    vwap=(pl.col("close") * pl.col("volume")).rolling_sum(20)
1    / pl.col("volume").rolling_sum(20)
).head(5)

8. Reshaping for Correlation Analysis

Pivot from long to wide for correlation / covariance matrices.

wide_returns = df.pivot(
    index="date",
    on="ticker",
    values="ret",
1).drop_nulls()

2corr_matrix = wide_returns.select(cs.numeric()).corr()
corr_matrix.head(5)

9. Performance: Categoricals & Streaming

Cast string columns to Categorical for memory savings. For datasets that exceed RAM, use LazyFrame + streaming to process in batches.

df = pl.scan_ipc("large_dataset.arrow")
.filter(pl.col("vol") > 0.3)
.group_by("ticker")
.agg(pl.col("ret").mean())
1.with_columns(pl.col("ticker").cast(pl.Categorical))
2.collect(streaming=True)

The Scenario: A Bond Pricer

Picture this: you’re writing a function to price bonds. You know you need to discount cashflows, so you need a yield curve. But “Yield Curve” is just an abstract idea. In reality, you might be dealing with:

• A Flat Curve (constant interest rate).
• A Zero Curve (interpolated from market rates).
• A Spline Curve (some fancy cubic math).

Your pricing engine shouldn’t care which one it’s using. It shouldn’t have if type(curve) == FlatCurve logic cluttering it up. It just wants a discount factor.

Abstract Base Classes (ABCs)

To keep things sane, we need rules. We need a contract that says: “If you want to be a Yield Curve, you must provide a discount factor.”

Python handles this with Abstract Base Classes (ABCs).

from abc import ABC, abstractmethod
import math

class YieldCurve(ABC):
    """
    Abstract base class for all yield curves.
    """

    @abstractmethod
    def discount_factor(self, t: float) -> float:
        """Calculate discount factor D(t) for time t."""
        pass

    def zero_rate(self, t: float) -> float:
        """
        Concrete method shared by all curves.
        Z(t) = -ln(D(t)) / t
        """
        if t <= 1e-9:
            return 0.0
        df = self.discount_factor(t)
        return -math.log(df) / t

Inheriting from ABC prevents anyone from creating a “plain” YieldCurve—it’s just a template. The @abstractmethod decorator is the enforcer: if a subclass doesn’t implement discount_factor, Python won’t let you instantiate it.

Notice we included zero_rate. Since the math linking zero rates and discount factors is universal (), we write it once here, and every single subclass gets it for free.

Concrete Implementations

With the ground rules established, let’s build something real. The simplest case is a Flat Forward Curve, where the rate is constant forever.

class FlatForwardCurve(YieldCurve):
    def __init__(self, rate: float):
        self.rate = rate

    def discount_factor(self, t: float) -> float:
        return math.exp(-self.rate * t)

Multiple Inheritance and Layering Behavior

Before we get to complex curves, let’s talk about one of Python’s superpowers: Multiple Inheritance. In many languages, a class can only have one parent. In Python, it can have many.

While this can get messy (the infamous “Diamond Problem”), it’s perfect for Mixins. A Mixin is a small class designed to “mix in” specific functionality to other classes.

Suppose we want to take our FlatForwardCurve (or any curve) and add a constant spread to it. Instead of rewriting the curve logic, we create a SpreadMixin.

class SpreadMixin:
    def __init__(self, spread: float, *args, **kwargs):
        self.spread = spread
1        super().__init__(*args, **kwargs)

    def discount_factor(self, t: float) -> float:
2        base_df = super().discount_factor(t)
3        return base_df * math.exp(-self.spread * t)

class ShiftedFlatCurve(SpreadMixin, FlatForwardCurve):
    pass

When we create ShiftedFlatCurve, Python’s Method Resolution Order (MRO) ensures that SpreadMixin runs first. Its super().discount_factor call then hops over to FlatForwardCurve.

shifted = ShiftedFlatCurve(rate=0.05, spread=0.02)
# Total rate effectively 0.07
print(f"Shifted DF(1.0): {shifted.discount_factor(1.0):.4f}")

Shifted DF(1.0): 0.9324

We just composed a new financial model on the fly without rewriting the flat curve logic.

Interpolation: A Fork in the Road

Now, let’s tackle curves built from market data. We have points (tenors and rates), but we need values between those points. We need interpolation.

This presents a classic design choice. Do we bake the interpolation logic into the curve class, or do we keep it separate? Let’s look at both Composition and Inheritance.

from typing import Protocol

# 1. Define the Strategy Interface
class Interpolator(Protocol):
    def interpolate(self, t: float, x: list[float], y: list[float]) -> float: ...

# 2. Implement Concrete Strategy
class LinearInterpolator:
    def interpolate(self, t: float, x: list[float], y: list[float]) -> float:
        # Simple flat extrapolation for endpoints
        if t <= x[0]:
            return y[0]
        if t >= x[-1]:
            return y[-1]

        # Linear search (simplified)
        for i in range(len(x) - 1):
            if x[i] <= t <= x[i + 1]:
                t1, t2 = x[i], x[i + 1]
                y1, y2 = y[i], y[i + 1]
                w = (t - t1) / (t2 - t1)
                return (1 - w) * y1 + w * y2
        return y[-1]

# 3. Use Composition in the Curve
class InterpolatedZeroCurve(YieldCurve):
    def __init__(
        self, times: list[float], rates: list[float], interpolator: Interpolator
    ):
        self.times = sorted(times)
        self.rates = [r for _, r in sorted(zip(times, rates))]
        self.interpolator = interpolator  # Composition

    def discount_factor(self, t: float) -> float:
        # Delegate the math to the strategy
        r = self.interpolator.interpolate(t, self.times, self.rates)
        return math.exp(-r * t)

class LinearInterpolationMixin:
    """
    Mixin that provides linear interpolation capability.
    """
    def interpolate_linear(self, t: float, x: list[float], y: list[float]) -> float:
        if t <= x[0]: return y[0]
        if t >= x[-1]: return y[-1]

        for i in range(len(x) - 1):
            if x[i] <= t <= x[i+1]:
                t1, t2 = x[i], x[i+1]
                y1, y2 = y[i], y[i+1]
                w = (t - t1) / (t2 - t1)
                return (1 - w) * y1 + w * y2
        return y[-1]

class MixinZeroCurve(LinearInterpolationMixin, YieldCurve):
    def __init__(self, times: list[float], rates: list[float]):
        self.times = sorted(times)
        self.rates = [r for _, r in sorted(zip(times, rates))]

    def discount_factor(self, t: float) -> float:
        # Use the inherited method
        r = self.interpolate_linear(t, self.times, self.rates)
        return math.exp(-r * t)

The Payoff: Polymorphism

Because we stuck to the YieldCurve contract, the pricing function doesn’t need to know about any of the complexity above.

from dataclasses import dataclass

@dataclass
class CashFlow:
    amount: float
    time: float

def price_bond(cashflows: list[CashFlow], curve: YieldCurve) -> float:
    price = 0.0
    for cf in cashflows:
        # Polymorphic call: Python decides at runtime which
        # discount_factor method to run!
        price += cf.amount * curve.discount_factor(cf.time)
    return price

Let’s test it:

# Define a bond: coupon of 5 at t=1, principal 105 at t=2
bond_cfs = [CashFlow(5, 1.0), CashFlow(105, 2.0)]

# 1. Price with Flat Curve
flat = FlatForwardCurve(rate=0.05)
print(f"Price (Flat): {price_bond(bond_cfs, flat):.2f}")

# 2. Price with Composition (Strategy)
linear_strategy = LinearInterpolator()
curve_comp = InterpolatedZeroCurve([0.5, 2.0], [0.04, 0.06], linear_strategy)
print(f"Price (Composition): {price_bond(bond_cfs, curve_comp):.2f}")

# 3. Price with Mixin
curve_mixin = MixinZeroCurve([0.5, 2.0], [0.04, 0.06])
print(f"Price (Mixin): {price_bond(bond_cfs, curve_mixin):.2f}")

Price (Flat): 99.76
Price (Composition): 97.90
Price (Mixin): 97.90

We swapped the entire mathematical engine underneath the hood—from flat rates to interpolated curves using different design patterns—and the pricing logic didn’t flinch.

Protocols: When Inheritance Feels Heavy

Inheritance is a commitment. Sometimes you want to use a class from a third-party library that looks like a yield curve but doesn’t inherit from your specific YieldCurve ABC.

Protocols (structural subtyping) solve this. A Protocol defines a shape: “I don’t care who your parents are, as long as you have a discount_factor method.”

from typing import runtime_checkable

@runtime_checkable
class Discountable(Protocol):
    def discount_factor(self, t: float) -> float: ...

class SimpleDiscounter:
    """
    This class does NOT inherit from YieldCurve.
    It just happens to have the right method.
    """
    def discount_factor(self, t: float) -> float:
        return 1 / (1 + 0.05 * t)  # Simple capitalization

def price_asset_structural(amount: float, t: float, model: Discountable) -> float:
    return amount * model.discount_factor(t)

simple = SimpleDiscounter()
print(f"Is compatible? {isinstance(simple, Discountable)}")
print(f"Price: {price_asset_structural(100, 1.0, simple):.2f}")

Is compatible? True
Price: 95.24

This lets you build loosely coupled systems that play nice with code you don’t own.

Wrapping Up

OOP gives us some powerful ways to keep our code organized and flexible.

• ABCs set the rules for what an object must do.
• Mixins let us stack features on top of each other like Lego blocks.
• Polymorphism lets our models swap in and out seamlessly.
• Protocols let us stay flexible without forcing a rigid hierarchy.

These patterns are what turn a collection of scripts into a proper library.

The Goal: A Pythonic Portfolio

We want a Portfolio class that stores a list of financial positions. But we don’t want a clunky interface like portfolio.get_position_by_ticker("AAPL"). We want the market-standard syntax:

• len(portfolio) to size up our exposure.
• portfolio["AAPL"] to get a quote instantly.
• for position in portfolio to audit our holdings.

Let’s start by defining a simple Position container. To keep our balance sheet clean, we’ll track the total USD value rather than quantity and price.

from __future__ import annotations

from dataclasses import dataclass
from collections.abc import Iterator

@dataclass
class Position:
    symbol: str
    value_usd: float

The Initial Portfolio Class

We start with a standard class definition. To index our strategy efficiently, we’ll store the positions in a dictionary keyed by their symbol. We name it _contents to signal it’s an internal implementation detail—a trade secret, if you will—encouraging users to access data through the public interface.

class Portfolio:
    def __init__(self, name: str, managers: tuple[str, ...], contents: list[Position] | None = None):
        self.name = name
        self.managers = managers
        # Store positions in a dictionary keyed by symbol for fast lookup
        self._contents = {pos.symbol: pos for pos in contents} if contents else {}

    def __repr__(self):
        return f"Portfolio(name={self.name!r}, managers={self.managers!r}, contents={list(self._contents.values())!r})"

# Create some data
pos1 = Position("AAPL", 15000.0)
pos2 = Position("GOOG", 140000.0)
p = Portfolio("Tech Fund", ("Alice", "Bob"), [pos1, pos2])
print(p)

Portfolio(name='Tech Fund', managers=('Alice', 'Bob'), contents=[Position(symbol='AAPL', value_usd=15000.0), Position(symbol='GOOG', value_usd=140000.0)])

We included __repr__ right away. This dunder method provides the “official” string representation, useful for debugging the object’s state.

Emulating a Collection

Right now, if we try to gauge the size of our portfolio, it raises a TypeError.

try:
    len(p)
except TypeError as e:
    print(f"Error: {e}")

Error: object of type 'Portfolio' has no len()

To enable the len() function, we implement __len__.

class Portfolio(Portfolio): # Inheriting to add methods incrementally for this post
    def __len__(self):
        return len(self._contents)

p = Portfolio("Tech Fund", ("Alice", "Bob"), [pos1, pos2])
print(f"Portfolio size: {len(p)}")

Portfolio size: 2

class Portfolio(Portfolio):
    def __getitem__(self, symbol: str) -> Position | None:
        return self._contents.get(symbol)

p = Portfolio("Tech Fund", ("Alice", "Bob"), [pos1, pos2])
print(f"AAPL position: {p['AAPL']}")
print(f"MSFT position: {p['MSFT']}") # Returns None

AAPL position: Position(symbol='AAPL', value_usd=15000.0)
MSFT position: None

class Portfolio(Portfolio):
    def __iter__(self) -> Iterator[Position]:
        return iter(self._contents.values())

p = Portfolio("Tech Fund", ("Alice", "Bob"), [pos1, pos2])

print("Iterating through portfolio:")
for pos in p:
    print(f" - {pos.symbol}: ${pos.value_usd:,.2f}")

Iterating through portfolio:
 - AAPL: $15,000.00
 - GOOG: $140,000.00

Membership and Truthiness: __contains__ and __bool__

We can already check membership via __iter__, but that’s O(N). Since we have a dictionary underneath, __contains__ gives us O(1) lookup.

We also want to know if our portfolio is empty. By default, Python checks len(), but implementing __bool__ allows us to be explicit about what constitutes a “truthy” portfolio.

class Portfolio(Portfolio):
    def __contains__(self, item: str | Position) -> bool:
        if isinstance(item, str):
            return item in self._contents
        if isinstance(item, Position):
            return item.symbol in self._contents
        return False

    def __bool__(self) -> bool:
        return bool(self._contents)

p = Portfolio("Tech Fund", ("Alice", "Bob"), [pos1, pos2])

print(f"Is 'AAPL' in p? {'AAPL' in p}")
print(f"Is 'MSFT' in p? {'MSFT' in p}")
print(f"Is p truthy? {bool(p)}")

empty_p = Portfolio("Empty", ("Nobody",))
print(f"Is empty_p truthy? {bool(empty_p)}")

Is 'AAPL' in p? True
Is 'MSFT' in p? False
Is p truthy? True
Is empty_p truthy? False

Operator Overloading: __add__ (Combining Portfolios)

In Python, objects can be combined using operators. If we have two portfolios, it makes intuitive sense to “add” them together using +.

We implement this via __add__. This isn’t just concatenation; it’s a consolidation. We need to combine managers and sum up the value of overlapping positions.

class Portfolio(Portfolio):
    def __add__(self, other: Portfolio) -> Portfolio:
        if not isinstance(other, Portfolio):
            return NotImplemented

        new_name = f"{self.name} + {other.name}"
        # Combine managers, removing duplicates
        new_managers = tuple(sorted(set(self.managers + other.managers)))
        # Merge contents
        all_positions = {}

        # Add positions from self
        for pos in self:
            all_positions[pos.symbol] = Position(pos.symbol, pos.value_usd)

        # Add positions from other
        for pos in other:
            if pos.symbol in all_positions:
                existing = all_positions[pos.symbol]
                existing.value_usd += pos.value_usd
            else:
                all_positions[pos.symbol] = Position(pos.symbol, pos.value_usd)
        return Portfolio(new_name, new_managers, list(all_positions.values()))

# Example Usage
p1 = Portfolio("Tech", ("Alice",), [Position("AAPL", 15000.0)])
p2 = Portfolio(
    "Growth", ("Bob",), [Position("AAPL", 8000.0), Position("MSFT", 30000.0)]
)

p3 = p1 + p2
print(f"Merged Portfolio: {p3}")
print(f"Merged AAPL: {p3['AAPL']}")

Merged Portfolio: Portfolio(name='Tech + Growth', managers=('Alice', 'Bob'), contents=[Position(symbol='AAPL', value_usd=23000.0), Position(symbol='MSFT', value_usd=30000.0)])
Merged AAPL: Position(symbol='AAPL', value_usd=23000.0)

String Representation: __repr__ vs __str__

Finally, we need to decide how our portfolio presents itself to the world.

• __repr__ (The Private Ledger): Unambiguous, developer-focused. It should ideally allow you to recreate the object.
• __str__ (The Public Face): Readable, user-focused. “What does this object represent to a human?”

If __str__ is not defined, Python falls back to __repr__. But we want a nice summary.

class Portfolio(Portfolio):
    def __str__(self):
        return f"Portfolio '{self.name}' with {len(self)} positions managed by {', '.join(self.managers)}"

p = Portfolio("Tech Fund", ("Alice", "Bob"), [pos1, pos2])
print(f"Str: {str(p)}")
print(f"Repr: {repr(p)}")

Str: Portfolio 'Tech Fund' with 2 positions managed by Alice, Bob
Repr: Portfolio(name='Tech Fund', managers=('Alice', 'Bob'), contents=[Position(symbol='AAPL', value_usd=15000.0), Position(symbol='GOOG', value_usd=140000.0)])

Why This Matters

By implementing these methods, we’ve turned a basic container into a robust and functional class.

• Lookup by Symbol: Instant access with p['AAPL'].
• Intuitive Iteration: Seamless traversal with for pos in p.
• Arithmetic: Combining objects made easy with p1 + p2.
• Expressiveness: The code reads clearly and naturally.

Summary

The Python Data Model is what makes Python feel like Python. It lets your custom objects play nice with all the built-in features you’re already using. Here’s the “greatest hits” of dunder methods we covered:

• __init__: For setting things up.
• __repr__: The “developer view” (detailed and exact).
• __str__: The “human view” (clean and readable).
• __len__: So len(your_obj) actually works.
• __getitem__: For that sweet square-bracket [] access.
• __iter__: To make your object loopable.
• __contains__: For fast x in your_obj checks.
• __bool__: To define what “empty” means for your object.
• __add__: So you can literally + your objects together.

These patterns are what make Python code feel like Python. In the next post, we’ll use inheritance and protocols to build a yield curve hierarchy.

Starting Simple: The Empty Class

Python’s dynamic nature allows for flexibility that can be surprising if you are coming from statically typed languages like C++ or Java. The most minimal class definition in Python is simply an empty block.

class Option:
    pass

This Option class might seem useless, but Python allows us to attach attributes to instances dynamically—a practice sometimes called “monkey patching” in broader contexts.

# Create an instance
my_option = Option()

# Attach attributes dynamically
my_option.strike = 100
my_option.expiry = "2025-12-20"
my_option.type = "Call"

print(f"Option strike: {my_option.strike}")

Option strike: 100

While flexible, this approach is risky for production systems, especially in finance where data integrity is critical. It offers no guarantee of structure—one Option might have a strike, while another has a strike_price. It also makes debugging difficult, as typos like my_option.stike = 100 pass silently until the code crashes later. IDEs and static analysis tools struggle to help you since they don’t know what attributes to expect.

Enforcing Structure: __init__

To fix this, we use the __init__ method. Think of it as your “initializer” (sometimes called a constructor). It runs the second an object is created, making sure every instance starts off with the right data in the right place.

Here’s how we can define a EuropeanOption class with a proper setup.

class EuropeanOption:
    def __init__(self, strike: float, expiry: str, option_type: str):
        self.strike = strike
        self.expiry = expiry
        self.option_type = option_type

# Now, we HAVE to provide these arguments to create an instance
# euro_option = EuropeanOption() # This would blow up with a TypeError
euro_option = EuropeanOption(100.0, "2025-12-20", "Call")

Class Attributes vs. Instance Attributes

The attributes strike, expiry, and option_type are instance attributes. They belong to a specific object; one option’s strike does not affect another’s.

Sometimes, however, we need to share data across all instances of a class. These are class attributes, defined directly in the class body.

class EuropeanOption:
    # Class attribute
    CONTRACT_SIZE = 100  # Standard lot size
    _DEFAULT_OPTION_TYPE = "Call" # Default for new options

    def __init__(self, strike: float, expiry: str, option_type: str):
        self.strike = strike  # Instance attribute
        self.expiry = expiry
        self.option_type = option_type

op1 = EuropeanOption(100, "2025-12-20", "Call")
op2 = EuropeanOption(110, "2025-12-20", "Put")

print(f"Option 1 contract size: {op1.CONTRACT_SIZE}")
print(f"Option 2 contract size: {op2.CONTRACT_SIZE}")

Option 1 contract size: 100
Option 2 contract size: 100

Changing EuropeanOption.CONTRACT_SIZE updates the value for all instances that haven’t explicitly overridden it.

The Three Method Types: An Overview

With self and class attributes covered, here are the three types of methods a class can have.

class EuropeanOption:
    def __init__(self, strike: float, option_type: str):
        self.strike = strike
        self.option_type = option_type

    def payoff(self, spot_price: float) -> float:
        if self.option_type == "Call":
            return max(spot_price - self.strike, 0.0)
        elif self.option_type == "Put":
            return max(self.strike - spot_price, 0.0)
        else:
            raise ValueError("Unknown option type")

call = EuropeanOption(100, "Call")
print(f"Spot 110, Call Payoff: {call.payoff(110)}")
print(f"Spot 90, Call Payoff: {call.payoff(90)}")

Spot 110, Call Payoff: 10
Spot 90, Call Payoff: 0.0

Class Methods

Sometimes we need a method that operates on the class itself rather than a specific instance. These are class methods, receiving the class (cls) as their first argument instead of self. They are marked with the @classmethod decorator.

A common use case for class methods is creating factory methods—alternative ways to instantiate the class.

class EuropeanOption:
    _DEFAULT_OPTION_TYPE = "Call"

    def __init__(self, strike: float, option_type: str):
        self.strike = strike
        self.option_type = option_type

    def __repr__(self):
        return f"EuropeanOption(strike={self.strike}, type='{self.option_type}')"

    @classmethod
    def from_string(cls, description: str):
        # Parses strings like "Call-100" or "Put-150"
        parts = description.split('-')
        option_type = parts[0]
        strike = float(parts[1])
        return cls(strike, option_type)

    @classmethod
    def set_default_option_type(cls, new_type: str):
        """Sets a new default option type for the class."""
        if new_type not in ["Call", "Put"]:
            raise ValueError("Option type must be 'Call' or 'Put'.")
        cls._DEFAULT_OPTION_TYPE = new_type

# Create an instance using the factory
option_from_str = EuropeanOption.from_string("Put-120")
print(f"Created from string: {option_from_str}")

# Demonstrate non-builder class method
print(f"Default option type before change: {EuropeanOption._DEFAULT_OPTION_TYPE}")
EuropeanOption.set_default_option_type("Put")
print(f"Default option type after change: {EuropeanOption._DEFAULT_OPTION_TYPE}")

Created from string: EuropeanOption(strike=120.0, type='Put')
Default option type before change: Call
Default option type after change: Put

Static Methods

A static method behaves like a regular function but lives within the class’s namespace. It doesn’t receive self or cls automatically. We use the @staticmethod decorator for utility functions that are logically related to the class but don’t need access to the class or instance state.

For an option class, a static method might implement a pricing formula component that is purely mathematical.

import math

class EuropeanOption:
    # ... (previous methods) ...

    @staticmethod
    def d1(S, K, T, r, sigma):
        """Calculates d1 term for Black-Scholes."""
        return (math.log(S / K) + (r + 0.5 * sigma ** 2) * T) / (sigma * math.sqrt(T))

# We can call it without an instance
d1_val = EuropeanOption.d1(S=100, K=100, T=1, r=0.05, sigma=0.2)
print(f"d1 value: {d1_val:.4f}")

d1 value: 0.3500

The Property Decorator: @property

In finance, invalid data can lead to significant errors. A negative strike price or a negative volatility is nonsensical. In languages like Java or C++, you typically implement getStrike() and setStrike() methods to handle validation. Python offers a cleaner alternative: the @property decorator.

This allows us to access a method as if it were an attribute, adding logic like validation seamlessly.

class EuropeanOption:
    def __init__(self, strike: float):
        # We assign to the property, triggering the setter validation
        self.strike = strike

    @property
    def strike(self):
        return self._strike

    @strike.setter
    def strike(self, value):
        if value < 0:
            raise ValueError("Strike price cannot be negative.")
        self._strike = value

opt = EuropeanOption(100)
print(f"Current Strike: {opt.strike}")

try:
    opt.strike = -50
except ValueError as e:
    print(f"Error caught: {e}")

Current Strike: 100
Error caught: Strike price cannot be negative.

Notice we use self._strike inside the property to store the actual value.

Access Control: Private vs. Protected

Python does not enforce strict private or protected keywords. Instead, it relies on naming conventions:

class EuropeanOption:
    def __init__(self, strike: float):
1        self._strike = strike
2        self.__valuation_model = "BS"

opt = EuropeanOption(100)

3print(opt._strike)
4# print(opt.__valuation_model)
5print(opt._EuropeanOption__valuation_model)

100
BS

In quantitative libraries, generally use _ for internal state that shouldn’t be part of the public API. Reserve __ for cases where you specifically need to avoid naming collisions in complex inheritance hierarchies.

Memory Optimization: __slots__

Standard Python objects store their attributes in a dictionary (__dict__), which allows for the dynamic behavior we saw earlier. However, dictionaries come with memory overhead.

If you are running a Monte Carlo simulation with millions of paths, this overhead can become a bottleneck. __slots__ tells Python to reserve space for only a specific set of attributes, removing the dynamic dictionary and saving memory.

import sys

class StandardOption:
    def __init__(self, strike, expiry):
        self.strike = strike
        self.expiry = expiry

class SlottedOption:
    __slots__ = ["strike", "expiry"]

    def __init__(self, strike, expiry):
        self.strike = strike
        self.expiry = expiry

# Compare memory usage
std_opt = StandardOption(100, "2025-12-20")
slot_opt = SlottedOption(100, "2025-12-20")

# Helper function to estimate size (rough approximation)
def get_size(obj):
    size = sys.getsizeof(obj)
    if hasattr(obj, "__dict__"):
        size += sys.getsizeof(obj.__dict__)
    return size

print(f"Standard Option Size: ~{get_size(std_opt)} bytes")
print(f"Slotted Option Size:  ~{get_size(slot_opt)} bytes")

Standard Option Size: ~344 bytes
Slotted Option Size:  ~48 bytes

The SlottedOption instance is more rigid—you cannot add new attributes like slot_opt.vega = ...—but it is significantly more memory-efficient.

Modern Python: Data Classes

Since Python 3.7, there is an even easier way to create classes that primarily store data. The @dataclass decorator automatically generates __init__, __repr__, __eq__, and other special methods for you, reducing boilerplate.

from dataclasses import dataclass

@dataclass
class OptionData:
    strike: float
    expiry: str
    option_type: str = "Call" # Default value

# No need to write __init__ or __repr__ manually!
opt_data = OptionData(100.0, "2025-12-20")
print(opt_data)

OptionData(strike=100.0, expiry='2025-12-20', option_type='Call')

Data classes are perfect for data transfer objects (DTOs) or when you simply need a structured container for information without complex initialization logic. They play very well with modern type checkers and IDEs.

Conclusion

We’ve gone from a chaotic, empty class to a structured, efficient unit that’s ready for some serious quant work. Here’s the quick checklist:

• __init__ is your safety net—use it to make sure your objects start off right.
• Instance vs. Class Attributes: Know when data belongs to one object and when it’s shared by everyone.
• Method Types: Use Instance methods for most things, Class methods for “factory” setups, and Static methods for pure utility.
• @property is your best friend for adding validation without making your code ugly.
• Access Control: Use _ to signal “internal use only” and __ when you really want to avoid naming collisions.
• __slots__ is a great “break in case of emergency” tool for saving memory in massive simulations.
• Data Classes are the modern, low-boilerplate way to build classes that just store info.

With these building blocks in place, the next post dives into Python’s data model — the dunder methods that make your classes feel like built-in types.

The Classics: venv and pip

python -m venv .venv

source .venv/bin/activate

.venv\Scripts\Activate.ps1

pip install requests

pip list

pip freeze > requirements.txt

pip install -r requirements.txt

The Modern Era: uv

venv and pip are reliable, but let’s be honest—they can be a bit clunky and slow. Enter uv. It’s a Python package and project manager written in Rust, and it is fast. It aims to replace pip, pip-tools, and virtualenv with one single binary.

uv init my-project
cd my-project

uv add requests

uv add --dev pytest ruff

uv python install 3.11
uv venv --python 3.11

uv python pin 3.12

# setup.py
1from setuptools import setup, find_packages

2setup(
    name='my_package',
    version='0.1.0',
    packages=find_packages(),
    install_requires=[
        'requests',
        'numpy',
    ],
    author='Your Name',
    author_email='your.email@example.com',
    description='A simple example package.',
    long_description=open('README.md').read(),
    long_description_content_type='text/markdown',
    url='https://github.com/yourusername/my_package',
    classifiers=[
        'Programming Language :: Python :: 3',
        'License :: OSI Approved :: MIT License',
        'Operating System :: OS Independent',
    ],
    python_requires='>=3.8',
)

python setup.py sdist bdist_wheel

uv build

Lists vs. Tuples: The Eager Iterables

Lists and tuples are the most common sequence types in Python. They are eager in the sense that all their elements are stored in memory at once. When you create a list of a million numbers, Python allocates memory for all of them.

my_list = [i for i in range(1_000_000)]
# This creates a list with 1,000,000 integers in memory.

This is fine for small to medium-sized datasets, but for very large datasets, this can lead to MemoryError.

Iterators: The Lazy Approach

An iterator is an object that represents a stream of data. It produces one item at a time, only when requested. The iterator protocol consists of two methods:

• __iter__(): Returns the iterator object itself.
• __next__(): Returns the next item from the stream. When there are no more items, it raises a StopIteration exception.

You can get an iterator from any iterable (like a list) using the iter() function.

my_list = [1, 2, 3]
my_iterator = iter(my_list)

print(next(my_iterator))  # Output: 1
print(next(my_iterator))  # Output: 2
print(next(my_iterator))  # Output: 3
# The next call would raise StopIteration

1
2
3

Generators: Simplified Iterators

Generators are a simpler way to create iterators. Instead of writing a class with __iter__ and __next__, you write a function that uses yield.

Here’s a simple generator that produces a sequence of numbers:

def number_generator(n):
    for i in range(n):
        yield i

gen = number_generator(1_000_000)
# No large list is created in memory here.
# The generator object 'gen' is created, ready to produce numbers.

The state of the generator is saved between yield calls. This allows it to resume where it left off.

trades_cashflows = [
    [10, 20, 30],  # Cashflows for Trade 1
    [15, 25],  # Cashflows for Trade 2
    [100, -10, 5],  # Cashflows for Trade 3
    110,  # Simple payment doesn't need to be in a list!
]

def flatten(list_of_lists):
    for item in list_of_lists:
        if isinstance(item, list):
            for subitem in item:
                yield subitem
        else:
            yield item

# The generator does not hold all cashflows in memory
all_cashflows_generator = flatten(trades_cashflows)

for cf in all_cashflows_generator:
    print(cf, end=" ")
# Output: 10 20 30 15 25 100 -10 5 110

10 20 30 15 25 100 -10 5 110 

Memory Efficiency in Action

To make our memory analysis cleaner, we can define a decorator. This is a more Pythonic way to wrap functions with common boilerplate code, like starting and stopping tracemalloc.

Let’s demonstrate the memory difference using a decorator with the standard library’s tracemalloc module. We’ll compare the memory usage of creating a list versus creating a generator.

import tracemalloc
from functools import wraps

def profile_memory(func):
    """A decorator to profile the memory usage of a function."""

    @wraps(func)
    def wrapper(*args, **kwargs):
        tracemalloc.start()
        result = func(*args, **kwargs)
        current, peak = tracemalloc.get_traced_memory()
        print(f"Function: {func.__name__}")
        print(
            f"Current memory usage is {current / 10**6:.6f}MB; Peak was {peak / 10**6:.6f}MB"
        )
        tracemalloc.stop()
        return result

    return wrapper

@profile_memory
def create_list(n):
    """This function creates a list of n numbers."""
    return [i for i in range(n)]

@profile_memory
def create_generator(n):
    """This function creates a generator of n numbers."""
    return (i for i in range(n))

n = 1_000_000
print("Profiling memory for list creation...")
my_list = create_list(n)

print("Profiling memory for generator creation...")
my_generator = create_generator(n)

# The generator itself is small. Let's profile consuming it.
@profile_memory
def consume_generator(gen):
    return list(gen)

print("Profiling memory for generator consumption...")
consumed_list = consume_generator(my_generator)

Profiling memory for list creation...
Function: create_list
Current memory usage is 40.441278MB; Peak was 40.441318MB
Profiling memory for generator creation...
Function: create_generator
Current memory usage is 0.000392MB; Peak was 0.000392MB
Profiling memory for generator consumption...
Function: consume_generator
Current memory usage is 40.441272MB; Peak was 40.441272MB

The output speaks for itself: creating the generator uses almost no memory. The cost only shows up when you actually consume it into a list.

Essential Iteration Tools: zip, sorted, enumerate

A few built-in functions that come up constantly:

• enumerate(iterable, start=0): When processing a series of cashflows, you might need to know the period number for each payment. enumerate is perfect for this.

  ::: {#a2707624 .cell execution_count=6} {.python .cell-code} cashflows = [100, 100, 100, 1100] # Coupon payments and principal for period, cf in enumerate(cashflows, 1): print(f"Period {period}: Cashflow = {cf}")

  ::: {.cell-output .cell-output-stdout} Period 1: Cashflow = 100 Period 2: Cashflow = 100 Period 3: Cashflow = 100 Period 4: Cashflow = 1100 ::: :::

• zip(*iterables): This function is very useful for combining different streams of data. For example, you can pair trade dates with their corresponding notionals.

  ::: {#bfcf62c9 .cell execution_count=7} {.python .cell-code} trade_dates = ['2025-11-05', '2025-11-06', '2025-11-07'] notionals = [1_000_000, 2_500_000, 500_000] for date, notional in zip(trade_dates, notionals): print(f"On {date}, we traded a notional of {notional:,}")

  ::: {.cell-output .cell-output-stdout} On 2025-11-05, we traded a notional of 1,000,000 On 2025-11-06, we traded a notional of 2,500,000 On 2025-11-07, we traded a notional of 500,000 ::: :::

• sorted(iterable, key=None, reverse=False): Sorting is a common task. You might want to sort a list of trades by maturity date or notional.

  ::: {#5792732b .cell execution_count=8} ``` {.python .cell-code} from dataclasses import dataclass from datetime import date

  @dataclass class Trade: trade_id: str maturity: date notional: float

  trades = [ Trade(‘T1’, date(2026, 12, 31), 10_000_000), Trade(‘T2’, date(2025, 12, 31), 5_000_000), Trade(‘T3’, date(2027, 12, 31), 15_000_000), ]

  # Sort trades by maturity date sorted_by_maturity = sorted(trades, key=lambda t: t.maturity) for trade in sorted_by_maturity: print(trade) ```

  ::: {.cell-output .cell-output-stdout} Trade(trade_id='T2', maturity=datetime.date(2025, 12, 31), notional=5000000) Trade(trade_id='T1', maturity=datetime.date(2026, 12, 31), notional=10000000) Trade(trade_id='T3', maturity=datetime.date(2027, 12, 31), notional=15000000) ::: :::

The itertools Module: A Treasure Trove for Financial Iteration

The itertools module is worth knowing well. Here are the ones I reach for most in financial work.

• itertools.chain(*iterables) and itertools.chain.from_iterable(iterable): Often you need to process items from several sequences in a row. chain lets you treat them as a single, continuous stream without merging them in memory. A great example is pricing a fixed-to-float swap leg, where initial coupon payments are fixed, and later ones are floating.

  chain.from_iterable is a useful variant that takes a single iterable of iterables.

  ::: {#ba501479 .cell execution_count=9} ``` {.python .cell-code} import itertools import random

  # First 2 years have fixed coupons fixed_leg = [50, 50, 50, 50]

  # Next 3 years have floating coupons (calculated for demonstration) floating_leg = [50 + random.uniform(-5, 5) for _ in range(6)]

  # We have a list of cashflow legs bond_legs = [fixed_leg, floating_leg]

  # We can use chain.from_iterable to chain them together full_swap_leg = itertools.chain.from_iterable(bond_legs)

  print(“Full cashflow stream for the leg:”) for cf in full_swap_leg: print(f”{cf:.2f}“, end=’ ’) ```

  ::: {.cell-output .cell-output-stdout} Full cashflow stream for the leg: 50.00 50.00 50.00 50.00 54.89 50.04 45.64 54.27 45.16 47.22 ::: :::

• itertools.accumulate(iterable[, func]): This is ideal for calculating cumulative sums or running products. A common use case is to calculate the cumulative P&L of a trading strategy.

  ::: {#a2a32f56 .cell execution_count=10} {.python .cell-code} import itertools daily_pnl = [150, -200, 50, 300, -100] cumulative_pnl = itertools.accumulate(daily_pnl) print(list(cumulative_pnl)) # Output: [150, -50, 0, 300, 200]

  ::: {.cell-output .cell-output-stdout} [150, -50, 0, 300, 200] ::: :::

  It can also model more complex recurrence relations, like the amortization of a loan. Let’s calculate the outstanding balance of a fixed-payment annuity until it’s paid off.

  ::: {#32cffe3d .cell execution_count=11} ``` {.python .cell-code} import itertools

  def outstanding_balance(balance, payment, rate): return balance * (1 + rate) - payment

  initial_notional = 1_000 interest_rate = 0.01 # Monthly rate (around 12% annually) monthly_payment = 50

  # Create an infinite stream of payments payments = itertools.repeat(monthly_payment)

  # The first argument to the lambda is the accumulated value (the balance) # The second argument is the next item from the iterable (the payment) balances = itertools.accumulate( payments, lambda balance, pmt: outstanding_balance(balance, pmt, interest_rate), initial=initial_notional, )

  # We can use takewhile to iterate until the loan is paid off (balance > 0) # The +1 is to see the final payment that brings the balance to <= 0 amortization_schedule = itertools.takewhile(lambda balance: balance > 0, balances)

  for i, balance in enumerate(amortization_schedule): print(f”Month {i+1}: {balance:,.2f}“)

  # Note: A proper amortization schedule would have a final smaller payment. # This example is to demonstrate the power of itertools. ```

  ::: {.cell-output .cell-output-stdout} Month 1: 1,000.00 Month 2: 960.00 Month 3: 919.60 Month 4: 878.80 Month 5: 837.58 Month 6: 795.96 Month 7: 753.92 Month 8: 711.46 Month 9: 668.57 Month 10: 625.26 Month 11: 581.51 Month 12: 537.33 Month 13: 492.70 Month 14: 447.63 Month 15: 402.10 Month 16: 356.12 Month 17: 309.69 Month 18: 262.78 Month 19: 215.41 Month 20: 167.56 Month 21: 119.24 Month 22: 70.43 Month 23: 21.14 ::: :::

• itertools.pairwise(iterable): As we’ve seen, this is ideal for working with consecutive items in a sequence. Calculating year fractions for a swap leg is a prime example.

  ::: {#62b2cb03 .cell execution_count=12} ``` {.python .cell-code} import itertools from datetime import date

  payment_dates = [date(2025, 1, 15), date(2025, 7, 15), date(2026, 1, 15)] def year_fraction(start, end): return (end - start).days / 365.25

  for start, end in itertools.pairwise(payment_dates): yf = year_fraction(start, end) print(f”Period: {start} to {end}, Year Fraction: {yf:.4f}“) ```

  ::: {.cell-output .cell-output-stdout} Period: 2025-01-15 to 2025-07-15, Year Fraction: 0.4956 Period: 2025-07-15 to 2026-01-15, Year Fraction: 0.5038 ::: :::

• itertools.cycle(iterable): Repeats a sequence indefinitely. This can be used to cycle through a set of risk scenarios or apply a repeating pattern of market data shocks.

  ::: {#9ff90afe .cell execution_count=13} {.python .cell-code} import itertools scenarios = itertools.cycle(['Base', 'Rate Up', 'Rate Down']) for _ in range(5): print(f"Running scenario: {next(scenarios)}")

  ::: {.cell-output .cell-output-stdout} Running scenario: Base Running scenario: Rate Up Running scenario: Rate Down Running scenario: Base Running scenario: Rate Up ::: :::

Conclusion

Understanding the difference between being “eager” (grabbing everything at once) and “lazy” (grabbing only what you need) is one of those leveling-up moments in Python. By leaning on iterators, generators, and the itertools library, you can write code that’s not just more efficient, but also much cleaner and easier to reason about.

The iterator protocol (__iter__ and __next__) we covered here is actually our first taste of Python’s data model — a topic we’ll dig into after covering class anatomy.

Functions

In Python, functions are “first-class citizens”. This just means you can treat them like any other variable. You can:

• assign them to variables,
• pass them as arguments to other functions,
• return them from functions.

This “functional programming” trait of Python is a core for some powerful patterns that wouldn’t work in some other (purely OOP) languages.

Let’s use a function from our previous post on Fibonacci numbers to see this in action.

def fibonacci_iterative(n: int) -> int:
    """Calculate the nth Fibonacci number using an iterative approach."""
    if n < 0:
        raise ValueError("Fibonacci is not defined for negative numbers.")
    if n < 2:
        return n

    a, b = 0, 1
    for _ in range(n - 1):
        a, b = b, a + b
    return b

Because functions are objects, they come with some handy attributes. For instance, you can get the docstring with __doc__ and the function’s name with __name__.

print(fibonacci_iterative.__doc__)
print(fibonacci_iterative.__name__)

Calculate the nth Fibonacci number using an iterative approach.
fibonacci_iterative

And just like other objects, functions inherit from the object base class.

isinstance(fibonacci_iterative, object)

True

Functions are more than callable blocks of code — and that flexibility is what makes closures and decorators possible.

Benchmarking Fibonacci Implementations

To really drive home the point that functions are first-class citizens, let’s put a few of our Fibonacci functions into a list and pass them to a benchmarking function. This function will test each one and see how they perform.

def fibonacci_iterative(n: int) -> int:
    """Calculate the nth Fibonacci number using an iterative approach."""
    if n < 0:
        raise ValueError("Fibonacci is not defined for negative numbers.")
    if n < 2:
        return n

    a, b = 0, 1
    for _ in range(n - 1):
        a, b = b, a + b
    return b

def fibonacci_recursive(n: int) -> int:
    """Calculate the nth Fibonacci number using a recursive approach."""
    if n < 0:
        raise ValueError("Fibonacci is not defined for negative numbers.")
    if n < 2:
        return n
    return fibonacci_recursive(n - 1) + fibonacci_recursive(n - 2)

FIBONACCI_CACHE: dict[int, int] = {}

def fibonacci_recursive_cached(n: int) -> int:
    """Calculate the nth Fibonacci number using recursion with memoization."""
    if n < 0:
        raise ValueError("Fibonacci is not defined for negative numbers.")
    if n < 2:
        return n

    if n in FIBONACCI_CACHE:
        return FIBONACCI_CACHE[n]

    result = fibonacci_recursive_cached(n - 1) + fibonacci_recursive_cached(n - 2)

    FIBONACCI_CACHE[n] = result
    return result

import time
from typing import Callable

def benchmark(
    functions: list[Callable[[int], int]],
    n: int
) -> None:
    """Benchmarks a list of functions."""
    for func in functions:
        start = time.perf_counter()
        func(n)
        end = time.perf_counter()
        print(f"Function {func.__name__} took {end - start:.6f} seconds.")

fib_functions = [fibonacci_recursive, fibonacci_recursive_cached, fibonacci_iterative]
benchmark(fib_functions, 30)

Function fibonacci_recursive took 0.133286 seconds.
Function fibonacci_recursive_cached took 0.000015 seconds.
Function fibonacci_iterative took 0.000004 seconds.

Closures

A closure is basically a function that remembers the environment in which it was created. Let’s use our get_greeter function to see what that means.

def get_greeter(greeting: str) -> Callable[[str],str]:
    """Returns a greeter function."""

    def greeter(name: str) -> str:
        return f"{greeting}, {name}!"

    return greeter

good_morning_greeter = get_greeter("Good morning")
print(good_morning_greeter("World"))

Good morning, World!

When we call get_greeter("Good morning"), we get a new greeter function back. This new function, which we’ve assigned to good_morning_greeter, “remembers” that the greeting variable was “Good morning”.

This is what a closure does: it “closes over” the variables from the scope where it was created. So even though the get_greeter function has finished running, good_morning_greeter still has access to the greeting variable.

We can even peek inside the closure with the __closure__ attribute, which shows us the variables it has captured.

good_morning_greeter.__closure__[0].cell_contents

'Good morning'

This shows that the value "Good morning" is tucked away in our good_morning_greeter function’s closure.

Closures are a key ingredient for decorators, which we’ll get to next. They also let us create “function factories” that can produce specialized functions.

For a more mathematical example, let’s create a function factory that builds a polynomial function from a tuple of coefficients.

A polynomial is defined as .

def polynomial_factory(coefficients: tuple[float, ...]) -> Callable:
    """
    A factory that creates a polynomial function from a tuple of coefficients.
    The coefficients are ordered from the highest power to the lowest.
    """
    def polynomial(x: float) -> float:
        """
        Evaluates the polynomial for a given x.
        """
        return sum(c * (x ** i) for i, c in enumerate(reversed(coefficients)))

    return polynomial

1p1 = polynomial_factory((2, 3, 5))

2p2 = polynomial_factory((1, 0, 0, -8))

print(p1(5))
print(p2(5))

70
117

Here, polynomial_factory returns a new polynomial function. This new function’s closure captures the coefficients tuple. So, p1 will always be the polynomial , and p2 will always be .

Decorators

Decorators are a neat way to add functionality to functions or classes without changing their code. Think of it as wrapping a function in another function to give it extra abilities.

In the last post, we used the @cache decorator to speed up our recursive Fibonacci function. Let’s try to build a simple version of that decorator ourselves.

1def my_cache(func: Callable) -> Callable:
    """A simple cache decorator."""
    _cache = {}

    def wrapper(*args):
        if args in _cache:
            return _cache[args]

        result = func(*args)
        _cache[args] = result
        return result

    return wrapper

@my_cache
def fibonacci_cached_by_me(n: int) -> int:
    """Calculate the nth Fibonacci number using recursion with our own cache decorator."""
    if n < 0:
        raise ValueError("Fibonacci is not defined for negative numbers.")
    if n < 2:
        return n
    return fibonacci_cached_by_me(n - 1) + fibonacci_cached_by_me(n - 2)

fibonacci_cached_by_me(30)

832040

Decorators can also take arguments. To do this, we create a “decorator factory” - a function that returns a decorator. Here’s one that repeats a function call a few times.

def repeat(times: int) -> Callable:
    """A decorator that repeats a function call a given number of times."""

    def decorator(func: Callable) -> Callable:
        def wrapper(*args, **kwargs):
            for _ in range(times):
                result = func(*args, **kwargs)
            return result

        return wrapper

    return decorator

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

say_hello("World")

Hello, World!
Hello, World!
Hello, World!

Decorators show up everywhere — Flask uses them for routing, pytest for fixtures. In the next post, we’ll use one to profile memory usage of iterators and generators.

Naive Recursive Approach

The Fibonacci sequence is defined by the recurrence relation: with seed values and .

A naive implementation of this in Python is a direct translation of the mathematical formula:

def fibonacci_recursive(n: int) -> int:
    """Calculate the nth Fibonacci number using a recursive approach."""
    if n < 0:
        raise ValueError("Fibonacci is not defined for negative numbers.")
    if n < 2:
        return n
    return fibonacci_recursive(n - 1) + fibonacci_recursive(n - 2)

This approach is very intuitive, but it is also very slow. For n=40, it already takes a noticeable amount of time to compute. The reason for this is that the function calls itself twice for each n, leading to an exponential growth of the call stack.

from time import perf_counter

start = perf_counter()
_ = fibonacci_recursive(40)
end = perf_counter()

print(f"Execution taken {end - start:.2f} seconds")

Execution taken 15.75 seconds

Visualizing the Call Stack

To better understand the problem, let’s visualize the call stack. We can create a “talkative” version of our function that logs every call.

from rich.console import Console
from rich.tree import Tree

def fibonacci_recursive_talkative(n: int) -> int:
    """Calculate the nth Fibonacci number using a recursive approach."""
    tree = Tree(f"fibonacci_recursive_talkative({n})")

    def worker(n: int, tree: Tree) -> int:
        """Calculate the nth Fibonacci number using a recursive approach."""
        node = tree.add(f"fibonacci_recursive({n}) called")
        if n < 0:
            raise ValueError("Fibonacci is not defined for negative numbers.")
        if n < 2:
            return n
        return worker(n - 1, node) + worker(n - 2, node)

    result = worker(n, tree)
    Console().print(tree)
    return result

For n=6, the call tree looks like this:

_ = fibonacci_recursive_talkative(6)

fibonacci_recursive_talkative(6)
└── fibonacci_recursive(6) called
    ├── fibonacci_recursive(5) called
    │   ├── fibonacci_recursive(4) called
    │   │   ├── fibonacci_recursive(3) called
    │   │   │   ├── fibonacci_recursive(2) called
    │   │   │   │   ├── fibonacci_recursive(1) called
    │   │   │   │   └── fibonacci_recursive(0) called
    │   │   │   └── fibonacci_recursive(1) called
    │   │   └── fibonacci_recursive(2) called
    │   │       ├── fibonacci_recursive(1) called
    │   │       └── fibonacci_recursive(0) called
    │   └── fibonacci_recursive(3) called
    │       ├── fibonacci_recursive(2) called
    │       │   ├── fibonacci_recursive(1) called
    │       │   └── fibonacci_recursive(0) called
    │       └── fibonacci_recursive(1) called
    └── fibonacci_recursive(4) called
        ├── fibonacci_recursive(3) called
        │   ├── fibonacci_recursive(2) called
        │   │   ├── fibonacci_recursive(1) called
        │   │   └── fibonacci_recursive(0) called
        │   └── fibonacci_recursive(1) called
        └── fibonacci_recursive(2) called
            ├── fibonacci_recursive(1) called
            └── fibonacci_recursive(0) called

As you can see, many values are calculated multiple times. For example, fibonacci_recursive(4) is calculated twice, fibonacci_recursive(3) is calculated three times, and so on. This is the reason for the inefficiency.

Memoization

We can improve the performance by storing the results of the function calls in a cache (a dictionary). This technique is called memoization.

FIBONACCI_CACHE: dict[int, int] = {}

def fibonacci_recursive_cached(n: int) -> int:
    """Calculate the nth Fibonacci number using recursion with memoization."""
    if n < 0:
        raise ValueError("Fibonacci is not defined for negative numbers.")
    if n < 2:
        return n

    if n in FIBONACCI_CACHE:
        return FIBONACCI_CACHE[n]

    result = fibonacci_recursive_cached(n - 1) + fibonacci_recursive_cached(n - 2)

    FIBONACCI_CACHE[n] = result
    return result

This version is much faster. However, it will fail for large n (e.g., n=8_000) because of Python’s recursion depth limit.

try:
    fibonacci_recursive_cached(8_000)
except RecursionError as e:
    print(e)

maximum recursion depth exceeded

Decorators for Caching

A more elegant way to implement memoization is by using a decorator. A decorator is a function that takes another function and extends its behavior without explicitly modifying it. Python’s functools module provides a built-in decorator lru_cache that does exactly what we need.

from functools import cache

@cache
def fibonacci_recursive_cached_decorator(n: int) -> int:
    """Calculate the nth Fibonacci number using recursion with memoization."""
    if n < 0:
        raise ValueError("Fibonacci is not defined for negative numbers.")
    if n < 2:
        return n
    return fibonacci_recursive_cached_decorator(
        n - 1
    ) + fibonacci_recursive_cached_decorator(n - 2)

This is the most concise and Pythonic way to write a cached recursive Fibonacci function.

Iterative Approach

Another way to solve the problem is to use an iterative approach. This is equivalent to tail recursion optimization.

def fibonacci_iterative(n: int) -> int:
    """Calculate the nth Fibonacci number using an iterative approach."""
    if n < 0:
        raise ValueError("Fibonacci is not defined for negative numbers.")
    if n < 2:
        return n

    a, b = 0, 1
    for _ in range(n - 1):
        a, b = b, a + b
    return b

This is the most efficient way (we’ll see) to calculate Fibonacci numbers in Python. It has a linear time complexity and constant space complexity.

Performance Comparison

To compare the performance of these implementations, we can use the perfplot library. It allows us to easily benchmark different functions over a range of input sizes.

import numba
import perfplot
import numpy as np

def fibonacci_internal_cached_decorator(n: int) -> int:
    """Calculate the nth Fibonacci number using recursion with memoization.

    This version uses an internal helper function decorated with @cache.
    This forces the cache to be local to this function.
    """

    @cache
    def helper(n: int) -> int:
        """Calculate the nth Fibonacci number using recursion with memoization."""
        if n < 0:
            raise ValueError("Fibonacci is not defined for negative numbers.")
        if n < 2:
            return n
        return helper(n - 1) + helper(n - 2)

    return helper(n)

fibonacci_iterative_jit = numba.njit(fibonacci_iterative)

1_ = fibonacci_iterative_jit(10)

def fibonacci_linalg_numpy(n):
    """Calculate the nth Fibonacci number using matrix exponentiation with NumPy."""

    if n <= 0:
        return 0
    if n == 1:
        return 1

    Q = np.array([[1, 1], [1, 0]], dtype=np.uint64)
2    result_matrix = np.linalg.matrix_power(Q, n - 1)
    return result_matrix[0, 0]

perfplot.show(
    setup=lambda n: n,
    kernels=[
        fibonacci_recursive,
        fibonacci_internal_cached_decorator,
        fibonacci_iterative,
    ],
    n_range=[i for i in range(1, 16)],
    xlabel="n",
    labels=[
        "recursive",
        "recursive cached",
        "iterative",
    ],
    title="Recursive vs cached vs iterative",
    show_progress=False,
    equality_check=False,
    logx=False,
    logy=True,
)

There are more advanced techniques and algorithms to compute Fibonacci numbers, below is a sneak peek for the future at two more efficient methods: using Numba’s JIT compilation and matrix exponentiation with NumPy.

perfplot.show(
    setup=lambda n: n,
    kernels=[
        fibonacci_iterative,
        fibonacci_iterative_jit,
        fibonacci_linalg_numpy,
    ],
    n_range=[2**i for i in range(10)],
    xlabel="n",
    labels=[
        "iterative (native)",
        "iterative (numba jit)",
        "matrix (numpy linalg)",
    ],
    equality_check=False,
    show_progress=False,
    logx=False,
    logy=True,
)

In the next post, we’ll use these Fibonacci implementations to explore first-class functions, closures, and decorators.

Books

• Fluent Python by Luciano Ramalho
• High Performance Python by Micha Gorelick and Ian Ozsvald
• CPython Internals by Anthony Shaw

YouTube

Blogs and Websites

• Real Python
• nietz
• Deciphering Glyph
• Python Weekly

Articles

Merger Arbitrage

Financial markets are where different participants interact through trading. The two primary things being traded are capital and risk. Capital is the money exchanged for the expectation of a future return, while risk is the uncertainty associated with that return.

Risk Management

Modern finance is built on the principle that risk can be quantified, analyzed, managed, and traded. The primary concepts employed in risk quantification are volatility and correlation. However, for merger arbitrage, these concepts and their related metrics from modern portfolio theory aren’t very useful. This is largely due to the relatively uncorrelated nature of the merger arbitrage strategy. The goal of pursuing such strategies is to generate alpha, which exhibits low correlation with broader market movements. While this can be a big advantage, especially when the market is unstable, it also creates unique risk management challenges.

Exposure Limits and Expected Losses

Exposure limits are a critical part of risk management for merger arbitrage portfolios. A key aspect of managing a merger arbitrage strategy is determining the maximum amount of risk that can be taken in a single position or a particular market segment. Limiting exposure reduces the probability of incurring significant losses from a single deal break.

This obviously means that a pure merger arbitrage portfolio needs to invest in multiple deals at once. The portfolio managers target a specific number of deals to be included in their strategy. Arbitrageurs can be “concentrated” (few deals, in-depth analysis) or “diversified” (many deals, spreading risk). According to a survey of risk management practices, merger arbitrageurs held an average of 36 positions, with a minimum of 25 and a maximum of 40. The maximum viable position size for each holding should be determined based on the specific investment goals.

The most straightforward approach to position limits is to cap the size of a single merger position within a portfolio, such as a 5% limit. These limits can be strict, meaning they are never exceeded, or flexible, allowing them to be exceeded if the arbitrageur has a strong belief in a deal’s success. In the latter case, there are usually two types of limits: a hard limit, which is the absolute maximum position size (red light), and a soft limit, which is the maximum position size that can be exceeded with justification (yellow light).

A more advanced approach to position limits is to set them based on the expected loss from a position and limit that to a certain percentage of the portfolio. We present a simplified procedure for calculating these limits, in the next sections.

There are other dimensions to consider when setting exposure limits. For example, the portfolio manager may want to limit the maximum exposure to a single sector or industry, which can help mitigate the risk of sector-specific events affecting multiple positions. This is, however, an easier task in theory than in practice, as the merger arbitrage universe is relatively small, and many deals are concentrated in a few sectors. As different industries go through cycles semi-independently, mergers might be concentrated in a few sectors at a time, making diversification difficult.

Limits can also be set on the types of transactions, such as restricting exposure to leveraged buyouts (LBOs), stock-for-stock transactions, etc., depending on the views and goals of the portfolio manager or the firm.

Another important risk management concept that is closely related to our calculation of exposure limits is the expected loss from a position. In the context of merger arbitrage, expected loss is the probability-weighted loss that an arbitrageur may incur if a merger deal fails to close. This is akin to the expected loss in the case of counterparty credit risk, where the expected loss is calculated as the product of the probability of default and the loss given default.

Stress Testing

As emphasized in previous chapters, merger arbitrage portfolios exhibit low sensitivity to broader market movements. It is useful to conceptualize a merger announcement as a phase transition wherein the target company’s stock price loses its historical correlation with the general market and its industry.

However, certain events can cause the stock price to revert from this phase transition and resume behaving like a typical stock. The most obvious example is the failure of the merger. Other events can also trigger this shift. For instance, during periods of market distress, risk arbitrage returns tend to become positively correlated with the market. This dual effect – uncorrelated returns in normal times and positive correlation with the market during distress – needs to be addressed in the context of stress testing. The whole goal is to assess the risk of a portfolio in extreme market conditions, so the modeling approach should take into account any non-linearities and regime-switching phenomena the portfolio may exhibit.

Option Pricing

Merger arbitrage is comparatively a low-volatility strategy, being a market-neutral investment. To amplify the returns, arbitrageurs often employ leverage. Two main vectors of leverage are available: borrowing cash (through margin or loans) to increase the size of the position, or using derivatives to increase the exposure to the underlying stock.

Conclusion

Risk management for merger arbitrage portfolios is complex and requires a careful look at their unique characteristics. The main feature of merger arbitrage is its low correlation with the broader market under normal market conditions, which provides an attractive risk-return profile. However, this low correlation can shift to a positive correlation during periods of market distress, which can lead to significant losses for arbitrageurs. Even during flat or bullish markets, the arbitrageur is exposed to the risk of the merger failing, which can result in a substantial drawdown. This requires unique expertise and constant monitoring of the merger proceedings, as well as the overall market outlook on the merger target and acquirer. Merger arbitrage is a good example of why risk management needs to be flexible. It challenges traditional techniques and requires a custom approach to handle its specific risks.

References

batched

This one’s a classic: you have a long list and you want to slice it up into chunks. Maybe you’re feeding data into a neural network or just trying not to hit a rate limit on an API.

Python 3.12 actually added this to itertools, but if you’re stuck on an older version or just want a standalone version, here’s how you can do it:

from __future__ import annotations
from collections.abc import Iterable
from itertools import islice
from sys import maxsize

def batched[T](
    iterable: Iterable[T],
    n: int,
    *,
    strict: bool = False,
) -> Iterable[tuple[T, ...]]:
    """Split an iterable into batches of size n."""
    if not 1 <= n <= maxsize:
        msg = "Batch size n must be at least one and at most sys.maxsize."
        raise ValueError(msg)

    iterator = iter(iterable)
    while batch := tuple(islice(iterator, n)):
        if strict and len(batch) != n:
            msg = "Incomplete batch for strict batching."
            raise ValueError(msg)
        yield batch

print(f"batched(range(10), 3): {list(batched(range(10), 3))}")

batched(range(10), 3): [(0, 1, 2), (3, 4, 5), (6, 7, 8), (9,)]

unbox

Ever have a list that should only have one thing in it? Maybe it’s a filtered database result or a unique ID. Instead of doing results[0] and hoping for the best, unbox makes sure your assumption is actually right.

It grabs that one item and throws a ValueError if it finds more than one (or zero). It’s a great way to catch bugs early.

def unbox[T](iterable: Iterable[T]) -> T:
    """Unbox an iterable if it contains a single element."""
    iterator = iter(iterable)
    first_value = next(iterator)
    try:
        _ = next(iterator)
        msg = "Iterable contains more than one element."
        raise ValueError(msg)
    except StopIteration:
        return first_value

print(f"unbox([42]): {unbox([42])}")

try:
    _ = unbox([1, 2])
except ValueError as e:
    print(f"unbox([1, 2]): {e}")

unbox([42]): 42
unbox([1, 2]): Iterable contains more than one element.

unzip

If you’ve ever used Python’s zip function, you know it’s a lifesaver for pairing up data. But what about the other way around? If you have a list of pairs and you want two separate lists, unzip is the tool for the job.

def unzip[T](iterable: Iterable[tuple[T, ...]]) -> tuple[Iterable[T], ...]:
    """Unzip an iterable of tuples."""
    zipped = zip(*iterable, strict=True)
    return tuple(zipped)

zipped_data = [(1, "a"), (2, "b"), (3, "c")]
unzipped_data = unzip(zipped_data)
print(f"unzip({zipped_data}): {[list(it) for it in unzipped_data]}")

unzip([(1, 'a'), (2, 'b'), (3, 'c')]): [[1, 2, 3], ['a', 'b', 'c']]

flatten_iterable

Nested lists are a headache. flatten_iterable lets you turn a messy, deeply nested structure into a single, clean list. It’s smart enough to leave strings and bytes alone, so you don’t end up with a list of individual characters when you didn’t mean to.

from collections.abc import Generator
from typing import cast

type NestedIterable[T] = Iterable[NestedIterable[T] | T]

def flatten_iterable[T](iterable: NestedIterable[T]) -> list[T]:
    """Flatten an iterable of iterables."""

    def _helper(lst: NestedIterable[T]) -> Generator[T]:
        for item in lst:
            if isinstance(item, Iterable) and not isinstance(item, (str, bytes)):
                yield from _helper(cast(NestedIterable[T], item))
            else:
                yield cast(T, item)

    return list(_helper(iterable))

nested_list = [1, [2, "a", [3]], "b"]
print(f"flatten_iterable({nested_list}): {flatten_iterable(nested_list)}")

flatten_iterable([1, [2, 'a', [3]], 'b']): [1, 2, 'a', 3, 'b']

flatten_string_key_dict

Nested dictionaries are great for structure, but they can be a pain to access. This function flattens them into a single level, using dots to join the keys (like parent.child.grandchild). It’s perfect for turning complex config files into something much easier to work with.

from collections.abc import Mapping

type NestedDict[T] = Mapping[str, NestedDict[T] | T]

def flatten_string_key_dict[T](dictionary: NestedDict[T]) -> dict[str, T]:
    """Flatten a nested string-keyed dictionary."""

    def _generate_items(
        d: NestedDict[T] | T, prefix: str = ""
    ) -> Generator[tuple[str, T]]:
        if isinstance(d, dict):
            for key, value in d.items():
                yield from _generate_items(value, prefix + key + ".")
        else:
            yield prefix[:-1], cast(T, d)

    return dict(_generate_items(dictionary))

nested_dict = {"a": 1, "b": {"c": 2, "d": {"e": 3}}, "f": 4}
print(
    f"flatten_string_key_dict({nested_dict}): "
    + f"{flatten_string_key_dict(nested_dict)}"
)

flatten_string_key_dict({'a': 1, 'b': {'c': 2, 'd': {'e': 3}}, 'f': 4}): {'a': 1, 'b.c': 2, 'b.d.e': 3, 'f': 4}

group_by_non_consecutive

If you’ve ever used itertools.groupby, you know the catch: your data must be sorted first, or it won’t work as expected. This helper function takes care of that for you by sorting the data before grouping it. It’s a bit more memory-heavy because it has to hold the whole list in memory to sort it, but for most everyday tasks, it’s a huge convenience.

import itertools
from collections.abc import Callable, Iterator
from typing import Any, Protocol, Self

class _SupportsLessThan(Protocol):
    def __lt__(self, other: Self) -> bool: ...

def group_by_non_consecutive[T, SLT: _SupportsLessThan](
    iterable: Iterable[T],
    *,
    key: Callable[[T], SLT] | None = None,
    reverse: bool = False,
) -> Iterator[tuple[SLT, Iterator[T]]]:
    """Sort and group an iterable by a key function.

    Unlike itertools.groupby, this function does not require the iterable
    to be pre-sorted. It first sorts the entire iterable and then applies
    the grouping.
    """
    if key is None:

        def default_key(x: T) -> SLT:
            return cast(SLT, x)

        key = default_key
    sorted_iterable = sorted(iterable, key=key, reverse=reverse)  # type: ignore[arg-type]
    return itertools.groupby(sorted_iterable, key=key)  # type: ignore[arg-type]

# With key function
data = ["apple", "banana", "ant", "bear", "apricot"]
print(f"group_by_non_consecutive({data}, key=lambda x: x[0])")
for key, group in group_by_non_consecutive(data, key=lambda x: x[0]):
    print(f"  {key}: {list(group)}")

# Without key function
data_nums = [1, 2, 1, 3, 2, 1]
print(f"group_by_non_consecutive({data_nums})")
for key, group in group_by_non_consecutive(data_nums):
    print(f"  {key}: {list(group)}")

group_by_non_consecutive(['apple', 'banana', 'ant', 'bear', 'apricot'], key=lambda x: x[0])
  a: ['apple', 'ant', 'apricot']
  b: ['banana', 'bear']
group_by_non_consecutive([1, 2, 1, 3, 2, 1])
  1: [1, 1, 1]
  2: [2, 2]
  3: [3]

Introduction

In this post, we’ll look at what it’s actually like for a mathematician to work in financial markets. We’ll go over the different roles you can land, the skills you actually need (beyond just knowing your way around a mathematical proof), and how to navigate the industry.

The Financial Ecosystem

When you first look at teh financial markets, they can seem like a chaotic mess of numbers, shouting (well, maybe less shouting now that everything is electronic), and complex jargon. But at their core, markets are just ecosystems where capital and risk are being exchanged. It’s a place where people who have money but no projects meet people who have projects but no money.

The characters you meet on the trading floor generally fall into a few buckets.

You have the Speculators, who are the ones taking on risk because they think they can predict where the price is going. They provide the liquidity that makes the market move. Regular people investing their retirement funds into stock exchenge indecies are also speculators. They are making a bet that the long term performance of the ecomomy outperforms inflation until they retire. This is historically a safe assuption, but still burdened with uncertainty.

Then you have Hedgers—these are the “insurance seekers” who already have a risk (like a farmer worried about wheat prices) and want to get rid of it.

In between them, you find the Arbitrageurs. These are the “market cleaners” who look for tiny inconsistencies in prices between different places. If gold is cheaper in London than in New York, they’ll buy in one and sell in the other until the prices align.

Finally, you have the Intermediaries (like brokers and market makers) who just want to make the trade happen and pocket a small fee for the service.

For a mathematician, this is a playground. Why? Because every single one of these types interactions with the market involves uncertainty, and if there’s one thing applied mathematicians are good at, it’s quantifying the unknown.

Why Do They Need Us?

You might wonder why a bank would hire someone who spent five years studying geometric bundles, clopen sets, branching processes or non-local unbounded operators. The reason is that modern finance is built on models that are essentially massive math problems. Catch-phrase here is “quantitative finance” but truly, nowadays all finance is quantitative.

Take pricing, for example. If you want to sell someone an option – the right to buy a stock at a certain price in six months – you need to know what that right is worth today. That involves stochastic calculus, partial differential equations, and a lot of numerical methods. It’s not just “guessing”; it’s solving a more complex Heat Equation in a financial context.

Then there’s Risk Management. After the 2008 crisis, “winging it” stopped being an option. Banks need to know, with a high degree of mathematical certainty, how much they could lose if the market takes a dive. This requires sophisticated probability theory and statistics to model “fat tails”—those rare but catastrophic events that standard models often miss.

Beyond pricing and risk, mathematicians heavily involved in Algorithmic Trading, where we use optimization and signal processing to execute trades in milliseconds, and Portfolio Optimization, where we use linear algebra to find the best possible balance between return and risk.

The Many Flavors of Quants

Not all “Quants” do the same thing. Depending on your interests, you might find yourself in very different environments. Some roles are all about the “hard math” of derivatives, while others are more about being a software engineer who happens to know what a Yield Curve is.

Case Study: From Jupyter Notebook to Production

To see the difference between the various Quant Analyst and Quant Developer roles in practice, let’s look at a concrete project: extracting implied probability distributions from option prices.

This is one of the quantitative finance standards. By looking at option prices across different strikes for a given expiry, we can extract the market’s consensus on the probability of the underlying asset reaching a certain price in the future. Mathematically, this is based on the Breeden-Litzenberger theorem, which states that the risk-neutral probability density function is proportional to the second derivative of the option price with respect to the strike price.

Imagine you have a basic implementation of this math in a Python script or Jupyter Notebook. It fits a smooth curve (like a cubic spline) to option prices and takes the numerical second derivative. It’s a neat math exercise, but in a professional setting, this script is just the starting point.

Here is how the paths of the Quant Analyst and the Quant Developer diverge:

The Reality of the Daily Grind

Life as a quant isn’t just solving theorems on a whiteboard. A huge chunk of your day is actually spent coding and testing. You might have a great idea for a model, but if you can’t implement it efficiently or prove that it works on historical data, it’s useless. You need to be comfortable with “messy” data—the kind that has holes, errors, and outliers that would make a pure mathematician cry.

There’s also a big communication aspect. You’ll often work with traders or managers who are brilliant at their jobs but don’t know a Taylor series from a Taylor Swift song. Being able to explain why a model is giving a certain result, without using Greek letters, is a superpower.

Finally, you have to deal with pressure and regulations. In some roles, if your code has a bug, you could lose millions of dollars in minutes. In others, you might spend weeks writing documentation for regulators to prove that your model isn’t going to blow up the economy. It’s a job that requires extreme attention to detail and a thick skin.

Where to Look for Work?

If you’re starting out, you have a few options depending on where you want to live.

In Poland, we have a surprisingly strong quant scene, with global institutions established in major cities (including UBS, BNY Mellon, Santander, Goldman Sachs, HSBC, and Revolut). Of course, the global hubs remain London, New York, and Hong Kong, but the barrier to entry has lowered significantly with the rise of remote and hybrid work.

Q&A

In my discussions with students and aspiring professionals, several questions tend to come up repeatedly. Here they are, along with my answers, to help shed more light on the realities of this job:

Final Thoughts

The transition from academia to finance can be jarring, but it’s incredibly rewarding if you like seeing your math have a direct, tangible impact on the world. If you’re interested in pursuing this path, my best advice is to get comfortable with Python or C++, learn the basics of probability, and start reading up on the “classics” of the field.

My Resume

Further Reading

Implementation

from __future__ import annotations

import sys

if sys.version_info >= (3, 11):
    from enum import StrEnum
    from typing import Self, override
else:
    from backports.strenum import StrEnum
    from typing_extensions import Self, override


class CaseInsensitiveStrEnum(StrEnum):
    """A case-insensitive string enum.

    This class extends the `StrEnum` class to provide case-insensitive member lookup.
    It also provides a custom `_generate_next_value_` method that returns the
    lowercase version of the member name for use with `auto()`.
    """

    @classmethod
    def __init_subclass__(cls, **kwargs: dict[str, Any]) -> None:
        """Implement the special hook that is called when a class is subclassed.

        It allows us to customize the class creation process without using metaclasses.
        """
        super().__init_subclass__(**kwargs)

        for member in cls:
            if not member.islower() or not member.value.islower():
                msg = f"Member '{member}' and value {member.value} must be lowercase."
                raise TypeError(msg)

    @override
    @staticmethod
    def _generate_next_value_(
        name: str, start: int, count: int, last_values: list[str]
    ) -> str:
        """Return the lower-cased version of the member name.

        This method is overridden to ensure that when `auto()` is used to create
        enum members, their values are the lowercase version of their names.
        """
        return name.lower()

    @override
    @classmethod
    def _missing_(cls, value: object) -> Self | None:
        """Provide case-insensitive member lookup.

        This method is called when a value is not found in the enum.
        It is overridden to perform a case-insensitive search for the member.
        """
        if not isinstance(value, str):
            return None

        value = value.lower()
        for member in cls:
            if member.name.lower() == value:
                return member

        return None

Example Usage

Here is an example of how to use the CaseInsensitiveStrEnum class:

from enum import auto

class TestEnum(CaseInsensitiveStrEnum):
    test = auto()
    enumz = auto()

print(f"List of members: {[member.name for member in TestEnum]}")
print(f"List of values: {[member.value for member in TestEnum]}")
print(f'Accessing "Test": {TestEnum("Test")}')
print(f'Accessing "test": {TestEnum("test")}')
print(f'Accessing "ENUMZ": {TestEnum("ENUMZ")}')


try:
    class TestEnum(CaseInsensitiveStrEnum):
        TEST = "TEST"  # This will raise a TypeError
except TypeError as e:
    print(e)