← Python

Method Chaining & Fluent Interfaces

← Method Chaining & Fluent Interfaces

Select a question from the sidebar

12 questions in this topic

Question 1 / 12

What is method chaining and how does it work in Python?

Method chaining is a pattern where multiple method calls are linked together in a single expression. Each method returns an object (usually self) that allows the next method to be called on it.

How it works:

Each method performs its operation
Each method returns self (or a new object of the same type)
The caller can chain .method() calls without intermediate variables

Two flavors:

Mutable chaining: Methods modify self and return self
Immutable chaining: Methods return a new object (like Django QuerySets)

Real-world examples:

Django QuerySet: User.objects.filter(...).exclude(...).order_by(...)
pandas: df.dropna().groupby('col').mean()
SQLAlchemy: session.query(User).filter(...).order_by(...).limit(10)
String methods: ' hello '.strip().upper().replace('H', 'J')

Pseudo Code

class Query:
    def filter(self, **kwargs):
        # apply filter
        return self  # enables chaining

    def order_by(self, field):
        # set ordering
        return self  # enables chaining

    def limit(self, n):
        # set limit
        return self  # enables chaining

# Usage:
result = Query().filter(active=True).order_by('name').limit(10)

Code

# Basic method chaining with return self
class Query:
    def __init__(self):
        self._filters = []
        self._order = None
        self._limit = None

    def filter(self, **kwargs):
        self._filters.append(kwargs)
        return self  # return self for chaining

    def order_by(self, field):
        self._order = field
        return self

    def limit(self, n):
        self._limit = n
        return self

    def build(self):
        parts = ["SELECT * FROM table"]
        for f in self._filters:
            conditions = ' AND '.join(f"{k}={v!r}" for k, v in f.items())
            parts.append(f"WHERE {conditions}")
        if self._order:
            parts.append(f"ORDER BY {self._order}")
        if self._limit:
            parts.append(f"LIMIT {self._limit}")
        return ' '.join(parts)

# Chained usage
result = (Query()
    .filter(active=True)
    .filter(role='admin')
    .order_by('name')
    .limit(10)
    .build())
print(result)
# SELECT * FROM table WHERE active=True WHERE role='admin' ORDER BY name LIMIT 10

# Python built-in chaining (strings are immutable -- each returns new string)
result = '  Hello, World!  '.strip().lower().replace('world', 'python')
print(result)  # 'hello, python!'

# List methods that DON'T support chaining (return None)
my_list = [3, 1, 2]
# WRONG: my_list.sort().append(4)  -- sort() returns None!
# RIGHT:
my_list.sort()
my_list.append(4)

SELECT * FROM table WHERE active=True WHERE role='admin' ORDER BY name LIMIT 10
hello, python!

Key Points

•Each method returns self (or a new object) to enable chaining
•Reduces intermediate variables and makes code more readable
•Python strings naturally support chaining (each method returns new string)
•Two styles: mutable (modify self) and immutable (return new object)

Gotchas

•Many built-in list methods (sort, append, extend, reverse) return None -- NOT chainable
•Mutable chaining modifies the original object -- callers may not expect this
•Long chains can be hard to debug -- which call failed?
•Returning self from __init__ is not possible (it must return None)

Method chaining: each method returns self, allowing .method().method().method(). Reduces variables, improves readability. Two styles: mutable (modify self) and immutable (return new copy).

•Return self from methods to enable chaining
•Strings chain naturally; list methods mostly return None

class Builder:
    def __init__(self):
        self.data = {}
    def set(self, key, value):
        self.data[key] = value
        return self  # enables chaining

result = Builder().set('a', 1).set('b', 2).data
print(result)  # {'a': 1, 'b': 2}

{'a': 1, 'b': 2}

list.sort() returns None -- not chainable

Question 2 / 12

How do you implement the Builder pattern with method chaining in Python?

The Builder pattern constructs complex objects step by step using method chaining. Instead of a constructor with many parameters, you set properties through named methods, then call .build() to create the final object.

Benefits:

Readable construction of complex objects
Optional parameters without None defaults
Validation can happen at build time
Immutable final objects from mutable builder

Pseudo Code

user = (UserBuilder()
    .name('Alice')
    .email('alice@example.com')
    .role('admin')
    .build())

# Clearer than:
# User('Alice', 'alice@example.com', None, 'admin', None, None, True)

Code

from dataclasses import dataclass
from typing import Optional

# The final immutable object
@dataclass(frozen=True)
class HttpRequest:
    method: str
    url: str
    headers: dict
    body: Optional[str]
    timeout: int
    auth: Optional[tuple]

# The builder
class HttpRequestBuilder:
    def __init__(self):
        self._method = 'GET'
        self._url = ''
        self._headers = {}
        self._body = None
        self._timeout = 30
        self._auth = None

    def method(self, method):
        self._method = method.upper()
        return self

    def url(self, url):
        self._url = url
        return self

    def header(self, key, value):
        self._headers[key] = value
        return self

    def body(self, body):
        self._body = body
        return self

    def timeout(self, seconds):
        self._timeout = seconds
        return self

    def auth(self, username, password):
        self._auth = (username, password)
        return self

    def build(self):
        if not self._url:
            raise ValueError('URL is required')
        if self._method in ('POST', 'PUT') and self._body is None:
            raise ValueError(f'{self._method} requires a body')
        return HttpRequest(
            method=self._method,
            url=self._url,
            headers=dict(self._headers),  # copy
            body=self._body,
            timeout=self._timeout,
            auth=self._auth,
        )

# Usage
request = (HttpRequestBuilder()
    .method('POST')
    .url('https://api.example.com/users')
    .header('Content-Type', 'application/json')
    .header('Accept', 'application/json')
    .body('{"name": "Alice"}')
    .timeout(10)
    .auth('user', 'pass')
    .build())

print(request.method)   # POST
print(request.url)      # https://api.example.com/users
print(request.headers)  # {'Content-Type': 'application/json', 'Accept': 'application/json'}

# Simpler GET request
get_request = (HttpRequestBuilder()
    .url('https://api.example.com/users')
    .header('Accept', 'application/json')
    .build())

print(get_request.method)   # GET (default)
print(get_request.timeout)  # 30 (default)

# Reusable builder template
base_builder = HttpRequestBuilder().header('Accept', 'application/json').timeout(15)
# Note: this shares state! Clone if reusing.

# HTML builder example
class HtmlBuilder:
    def __init__(self, tag):
        self._tag = tag
        self._children = []
        self._attrs = {}

    def attr(self, key, value):
        self._attrs[key] = value
        return self

    def child(self, tag_or_text):
        if isinstance(tag_or_text, HtmlBuilder):
            self._children.append(tag_or_text)
        else:
            self._children.append(str(tag_or_text))
        return self

    def build(self):
        attrs = ' '.join(f'{k}="{v}"' for k, v in self._attrs.items())
        opening = f'<{self._tag} {attrs}>' if attrs else f'<{self._tag}>'
        children = ''.join(
            c.build() if isinstance(c, HtmlBuilder) else c
            for c in self._children
        )
        return f'{opening}{children}</{self._tag}>'

html = (HtmlBuilder('div')
    .attr('class', 'container')
    .child(HtmlBuilder('h1').child('Title'))
    .child(HtmlBuilder('p').attr('class', 'text').child('Hello world'))
    .build())
print(html)
# <div class="container"><h1>Title</h1><p class="text">Hello world</p></div>

POST
https://api.example.com/users
{'Content-Type': 'application/json', 'Accept': 'application/json'}
GET
30
<div class="container"><h1>Title</h1><p class="text">Hello world</p></div>

Key Points

•Builder collects configuration via chained methods, then build() creates the object
•Validation happens in build(), not during construction
•Final object can be immutable (frozen dataclass) while builder is mutable
•Each method returns self for chaining; build() returns the final product

Gotchas

•Builder instances are mutable -- reusing a builder between builds shares state
•Forgetting to call build() means you get the builder, not the product
•Python's keyword arguments often eliminate the need for a Builder pattern
•Type checkers may not know the return type of chained methods -- use type hints

Builder pattern: set properties via chained methods, then .build() creates the final object. Separates construction from representation. Each setter returns self.

•Chain setters, call build() to produce result
•Validates at build time, not at set time

class QueryBuilder:
    def __init__(self):
        self._table = ''
        self._where = []
    def table(self, name):
        self._table = name
        return self
    def where(self, condition):
        self._where.append(condition)
        return self
    def build(self):
        sql = f"SELECT * FROM {self._table}"
        if self._where:
            sql += " WHERE " + " AND ".join(self._where)
        return sql

print(QueryBuilder().table('users').where('active=1').where('age>18').build())

SELECT * FROM users WHERE active=1 AND age>18

Python kwargs often make Builder pattern unnecessary

Question 3 / 12

How does pandas-style method chaining work and why is it powerful?

Pandas DataFrames support extensive method chaining where each operation returns a new DataFrame. This creates readable data transformation pipelines.

Why it works:

Most pandas methods return a new DataFrame (immutable style)
Methods like assign(), query(), pipe() are designed for chaining
pipe() lets you chain custom functions

The `pipe()` method:

df.pipe(func, *args) is equivalent to func(df, *args) -- lets you chain any function that takes a DataFrame as its first argument.

Pseudo Code

result = (df
    .query('age > 18')
    .assign(full_name=lambda x: x['first'] + ' ' + x['last'])
    .groupby('department')
    .agg({'salary': 'mean'})
    .sort_values('salary', ascending=False)
    .head(10))

Code

import pandas as pd

# Sample data
df = pd.DataFrame({
    'name': ['Alice', 'Bob', 'Charlie', 'Diana', 'Eve'],
    'department': ['Engineering', 'Marketing', 'Engineering', 'Marketing', 'Engineering'],
    'salary': [95000, 65000, 110000, 70000, 105000],
    'years': [5, 3, 8, 2, 6],
    'active': [True, True, True, False, True],
})

# Method chaining pipeline
result = (df
    .query('active == True')                          # filter
    .assign(
        salary_k=lambda x: x['salary'] / 1000,       # add computed column
        experience=lambda x: x['years'].apply(
            lambda y: 'senior' if y >= 5 else 'junior'
        ),
    )
    .sort_values('salary', ascending=False)            # sort
    .reset_index(drop=True)                            # clean index
)
print(result)

# Groupby chaining
stats = (df
    .query('active == True')
    .groupby('department')
    .agg(
        avg_salary=('salary', 'mean'),
        headcount=('name', 'count'),
        max_years=('years', 'max'),
    )
    .sort_values('avg_salary', ascending=False)
    .reset_index()
)
print(stats)

# Using pipe() for custom functions
def add_salary_band(df, low=60000, high=100000):
    return df.assign(
        band=pd.cut(df['salary'], bins=[0, low, high, float('inf')],
                     labels=['low', 'mid', 'high'])
    )

def filter_department(df, dept):
    return df.query(f'department == "{dept}"')

result = (df
    .pipe(add_salary_band, low=70000, high=100000)
    .pipe(filter_department, dept='Engineering')
    .sort_values('salary')
)
print(result)

# String method chaining
result = (df
    .assign(name_upper=lambda x: x['name'].str.upper())
    .assign(name_len=lambda x: x['name'].str.len())
)
print(result[['name', 'name_upper', 'name_len']])

# Chaining with rename and drop
cleaned = (df
    .rename(columns={'name': 'employee_name', 'years': 'tenure'})
    .drop(columns=['active'])
    .set_index('employee_name')
)
print(cleaned)

Key Points

•Most pandas methods return new DataFrames, enabling natural chaining
•assign() adds computed columns; query() filters with string expressions
•pipe() lets you chain any function that takes a DataFrame first
•Parentheses allow multi-line chains without backslashes

Gotchas

•Chaining creates new DataFrames at each step -- can use more memory than in-place operations
•Some pandas methods modify in-place (inplace=True) and return None -- breaks chains
•Long chains can be hard to debug -- extract intermediate steps when troubleshooting
•query() uses string expressions which bypass IDE autocomplete and type checking

Pandas methods return new DataFrames, enabling df.query(...).assign(...).groupby(...).sort_values(...). Use pipe() to chain custom functions. Wrap in parentheses for multi-line.

•Each method returns a new DataFrame
•pipe() for chaining custom functions

result = (df
    .query('active == True')
    .assign(salary_k=lambda x: x['salary'] / 1000)
    .groupby('department')
    .agg({'salary_k': 'mean'})
    .sort_values('salary_k', ascending=False))

inplace=True returns None -- breaks chains

Question 4 / 12

How does SQLAlchemy query chaining work?

SQLAlchemy queries are built by chaining methods on a Query object (legacy) or select() statement (2.0 style). Each method returns a new query object with the additional constraint.

Key chainable methods:

filter() / where(): Add WHERE clauses
order_by(): Set ordering
limit() / offset(): Pagination
join(): Table joins
group_by() / having(): Grouping
options(): Eager loading configuration

Queries are lazy -- SQL is only generated and executed when you call .all(), .first(), .one(), or iterate.

Pseudo Code

# Legacy (1.x)
query = session.query(User).filter(...).order_by(...).limit(10)

# Modern (2.0)
stmt = select(User).where(...).order_by(...).limit(10)
result = session.execute(stmt)

Code

from sqlalchemy import create_engine, select, func, and_, or_
from sqlalchemy.orm import Session, DeclarativeBase, Mapped, mapped_column, relationship
from sqlalchemy import String, Integer, Boolean, ForeignKey

class Base(DeclarativeBase):
    pass

class User(Base):
    __tablename__ = 'users'
    id: Mapped[int] = mapped_column(primary_key=True)
    name: Mapped[str] = mapped_column(String(100))
    email: Mapped[str] = mapped_column(String(200), unique=True)
    active: Mapped[bool] = mapped_column(Boolean, default=True)
    department: Mapped[str] = mapped_column(String(50))
    posts: Mapped[list['Post']] = relationship(back_populates='author')

class Post(Base):
    __tablename__ = 'posts'
    id: Mapped[int] = mapped_column(primary_key=True)
    title: Mapped[str] = mapped_column(String(200))
    user_id: Mapped[int] = mapped_column(ForeignKey('users.id'))
    published: Mapped[bool] = mapped_column(Boolean, default=False)
    author: Mapped['User'] = relationship(back_populates='posts')

# SQLAlchemy 2.0 style chaining
engine = create_engine('sqlite:///:memory:')
Base.metadata.create_all(engine)

with Session(engine) as session:
    # Build query step by step
    stmt = (
        select(User)
        .where(User.active == True)
        .where(User.department == 'Engineering')
        .order_by(User.name)
        .limit(10)
    )
    users = session.execute(stmt).scalars().all()

    # Complex chaining with joins
    stmt = (
        select(User, func.count(Post.id).label('post_count'))
        .join(Post, User.id == Post.user_id)
        .where(Post.published == True)
        .group_by(User.id)
        .having(func.count(Post.id) >= 5)
        .order_by(func.count(Post.id).desc())
    )
    results = session.execute(stmt).all()

    # Conditional chaining
    def search_users(name=None, department=None, active_only=True):
        stmt = select(User)
        if name:
            stmt = stmt.where(User.name.ilike(f'%{name}%'))
        if department:
            stmt = stmt.where(User.department == department)
        if active_only:
            stmt = stmt.where(User.active == True)
        return stmt.order_by(User.name)

    stmt = search_users(name='alice', active_only=True)
    results = session.execute(stmt).scalars().all()

    # OR conditions
    stmt = (
        select(User)
        .where(or_(
            User.department == 'Engineering',
            User.department == 'Research'
        ))
        .order_by(User.name)
    )

    # Subquery chaining
    subq = (
        select(Post.user_id)
        .where(Post.published == True)
        .group_by(Post.user_id)
        .having(func.count(Post.id) > 3)
        .subquery()
    )
    stmt = select(User).where(User.id.in_(select(subq.c.user_id)))

Key Points

•Each chained method returns a new statement object (immutable chaining)
•Queries are lazy -- SQL executes only when .all(), .first(), or iterate
•Conditional chaining lets you build dynamic queries
•SQLAlchemy 2.0 uses select() statements instead of session.query()

Gotchas

•Each .where() adds an AND condition; use or_() for OR logic
•Forgetting session.execute() means the query never runs
•.scalars().all() extracts model instances; .all() returns Row tuples
•Chaining .where() multiple times uses AND -- use or_() explicitly for OR

SQLAlchemy queries chain with .where().order_by().limit(). Each call returns a new statement (immutable). Lazy -- executes on .all()/.first(). Use select() in 2.0 style.

•Immutable chaining -- each call returns new statement
•Lazy execution on .all()/.first()

from sqlalchemy import select

stmt = (
    select(User)
    .where(User.active == True)
    .order_by(User.name)
    .limit(10)
)
results = session.execute(stmt).scalars().all()

Multiple .where() are ANDed; use or_() for OR

Question 5 / 12

How do you design a chainable API class in Python?

A chainable (fluent) API requires careful design to be intuitive and robust.

Design principles:

Return self from every configuration method
Separate configuration from execution (builder methods vs terminal operations)
Use type hints to help IDE autocomplete
Support both chained and non-chained usage
Make terminal operations clear (e.g., .execute(), .build(), .send())

Terminal vs non-terminal methods:

Non-terminal: Return self for continued chaining (.filter(), .sort())
Terminal: Return the final result (.execute(), .count(), .first())

Pseudo Code

class Chainable:
    def config_method(self, ...) -> 'Chainable':  # non-terminal
        # modify state
        return self

    def terminal_method(self) -> Result:  # terminal
        # compute and return result
        return result

Code

from __future__ import annotations
from typing import TypeVar, Generic, Callable, Any

# Example: Email builder with chainable API
class EmailMessage:
    def __init__(self):
        self._to: list[str] = []
        self._cc: list[str] = []
        self._subject: str = ''
        self._body: str = ''
        self._attachments: list[str] = []
        self._html: bool = False

    # Non-terminal methods (return self)
    def to(self, *addresses: str) -> EmailMessage:
        self._to.extend(addresses)
        return self

    def cc(self, *addresses: str) -> EmailMessage:
        self._cc.extend(addresses)
        return self

    def subject(self, text: str) -> EmailMessage:
        self._subject = text
        return self

    def body(self, text: str) -> EmailMessage:
        self._body = text
        return self

    def html(self) -> EmailMessage:
        self._html = True
        return self

    def attach(self, filepath: str) -> EmailMessage:
        self._attachments.append(filepath)
        return self

    # Terminal method
    def send(self) -> dict:
        if not self._to:
            raise ValueError('At least one recipient required')
        if not self._subject:
            raise ValueError('Subject required')

        result = {
            'to': self._to,
            'cc': self._cc,
            'subject': self._subject,
            'body': self._body,
            'html': self._html,
            'attachments': self._attachments,
            'status': 'sent',
        }
        print(f"Sending email to {', '.join(self._to)}: {self._subject}")
        return result

    def preview(self) -> str:
        """Terminal method for debugging."""
        return (f"To: {', '.join(self._to)}\n"
                f"CC: {', '.join(self._cc)}\n"
                f"Subject: {self._subject}\n"
                f"Body: {self._body[:100]}...")

# Usage
result = (EmailMessage()
    .to('alice@example.com', 'bob@example.com')
    .cc('manager@example.com')
    .subject('Weekly Report')
    .body('<h1>Report</h1><p>All metrics are up.</p>')
    .html()
    .attach('report.pdf')
    .send())

print(result['status'])  # 'sent'

# Preview without sending
preview = (EmailMessage()
    .to('test@example.com')
    .subject('Test')
    .body('Hello')
    .preview())
print(preview)

# Validation chain example
class Validator:
    def __init__(self, value: Any):
        self._value = value
        self._errors: list[str] = []

    def required(self) -> Validator:
        if self._value is None or self._value == '':
            self._errors.append('Value is required')
        return self

    def min_length(self, n: int) -> Validator:
        if isinstance(self._value, str) and len(self._value) < n:
            self._errors.append(f'Must be at least {n} characters')
        return self

    def max_length(self, n: int) -> Validator:
        if isinstance(self._value, str) and len(self._value) > n:
            self._errors.append(f'Must be at most {n} characters')
        return self

    def matches(self, pattern: str) -> Validator:
        import re
        if isinstance(self._value, str) and not re.match(pattern, self._value):
            self._errors.append(f'Must match pattern {pattern}')
        return self

    # Terminal
    def is_valid(self) -> bool:
        return len(self._errors) == 0

    def errors(self) -> list[str]:
        return self._errors

# Usage
v = Validator('ab').required().min_length(3).max_length(50)
print(v.is_valid())  # False
print(v.errors())    # ['Must be at least 3 characters']

Sending email to alice@example.com, bob@example.com: Weekly Report
sent
To: test@example.com
CC:
Subject: Test
Body: Hello...
False
['Must be at least 3 characters']

Key Points

•Non-terminal methods return self; terminal methods return the result
•Type hint return as the class name for IDE autocomplete on chains
•Validate in terminal methods, not configuration methods
•Separate configuration (chainable) from execution (terminal)

Gotchas

•Forgetting to return self silently returns None, breaking the chain
•Type hints with string annotations need from __future__ import annotations
•Mutable state means chaining is not thread-safe by default
•Terminal methods should be clearly named to indicate they end the chain

Design rules: config methods return self (non-terminal), result methods return data (terminal). Type hint return as class name. Validate at terminal call.

•Return self for chaining, return result for terminal
•Type hints enable IDE autocomplete on chains

class Email:
    def to(self, addr) -> 'Email':
        self._to = addr
        return self  # non-terminal
    def subject(self, text) -> 'Email':
        self._subject = text
        return self  # non-terminal
    def send(self) -> dict:  # terminal
        return {'to': self._to, 'subject': self._subject}

Forgetting return self silently returns None

Question 6 / 12

What is immutable chaining and how does it differ from mutable chaining?

Mutable chaining

Each method modifies self in place and returns self. The original object changes.

obj.filter(x).sort(y)  # obj is modified

Immutable chaining

Each method creates and returns a new object with the modification. The original is untouched.

new_obj = obj.filter(x).sort(y)  # obj is unchanged

When to use each:

Mutable: Simpler, less memory, good for builders that are used once
Immutable: Safer, no side effects, good for shared/reusable objects (Django QuerySets, pandas DataFrames)

Django QuerySets use immutable chaining -- each .filter() returns a NEW QuerySet.

Pseudo Code

Mutable: obj.add(1).add(2)  -> obj has [1, 2]
Immutable: new = obj.add(1).add(2)  -> obj has [], new has [1, 2]

Code

import copy

# Mutable chaining
class MutableQuery:
    def __init__(self):
        self.filters = []
        self.ordering = None

    def filter(self, condition):
        self.filters.append(condition)  # modifies self
        return self

    def order_by(self, field):
        self.ordering = field  # modifies self
        return self

q = MutableQuery()
q.filter('active=True')
q2 = q.filter('role=admin')  # q and q2 are the SAME object!
print(q is q2)  # True
print(q.filters)  # ['active=True', 'role=admin'] -- q was modified!

# Immutable chaining (like Django QuerySets)
class ImmutableQuery:
    def __init__(self, filters=None, ordering=None):
        self._filters = list(filters or [])
        self._ordering = ordering

    def filter(self, condition):
        # Return a NEW object with the additional filter
        new_filters = self._filters + [condition]
        return ImmutableQuery(filters=new_filters, ordering=self._ordering)

    def order_by(self, field):
        return ImmutableQuery(filters=self._filters, ordering=field)

    def __repr__(self):
        return f"Query(filters={self._filters}, order={self._ordering})"

base = ImmutableQuery()
active = base.filter('active=True')
admins = active.filter('role=admin')
regular = active.filter('role=user')

print(base)     # Query(filters=[], order=None) -- unchanged!
print(active)   # Query(filters=['active=True'], order=None)
print(admins)   # Query(filters=['active=True', 'role=admin'], order=None)
print(regular)  # Query(filters=['active=True', 'role=user'], order=None)

# Branching works safely with immutable chaining
print(admins is not regular)  # True -- different objects

# Using copy for immutable-style with less boilerplate
class CopyChain:
    def __init__(self):
        self.filters = []
        self.limit_val = None

    def _clone(self):
        return copy.deepcopy(self)

    def filter(self, condition):
        clone = self._clone()
        clone.filters.append(condition)
        return clone

    def limit(self, n):
        clone = self._clone()
        clone.limit_val = n
        return clone

base = CopyChain()
q1 = base.filter('a=1').limit(10)
q2 = base.filter('b=2').limit(5)
print(base.filters)  # [] -- unchanged
print(q1.filters)    # ['a=1']
print(q2.filters)    # ['b=2']

True
['active=True', 'role=admin']
Query(filters=[], order=None)
Query(filters=['active=True'], order=None)
Query(filters=['active=True', 'role=admin'], order=None)
Query(filters=['active=True', 'role=user'], order=None)
True
[]
['a=1']
['b=2']

Key Points

•Mutable: modifies self, returns self. Simpler but dangerous with shared references.
•Immutable: returns new object each time. Safer, supports branching.
•Django QuerySets and pandas DataFrames use immutable chaining.
•Use _clone() / copy.deepcopy() for immutable-style with less boilerplate.

Gotchas

•Mutable chaining means q1 = q.filter(x); q2 = q.filter(y) gives SAME object -- q1 and q2 are identical
•Immutable chaining uses more memory (copies per call) but is much safer
•deepcopy can be slow for large objects -- optimize with shallow copy + selective deep copy
•Forgetting to use the returned value in immutable chains means changes are lost

Mutable: modifies + returns self (shared state). Immutable: returns new object (safe branching). Django/pandas use immutable. Mutable is simpler but risky with shared references.

•Immutable returns new object; mutable returns self
•Immutable is safer for branching queries

# Immutable: each call returns new object
class Query:
    def __init__(self, filters=None):
        self._filters = list(filters or [])
    def filter(self, cond):
        return Query(self._filters + [cond])  # new object!

base = Query()
q1 = base.filter('a=1')  # base unchanged
q2 = base.filter('b=2')  # base unchanged, q2 != q1

Mutable chaining shares state between references

Question 7 / 12

How do enter and exit enable context manager chaining?

Context managers (with statement) use __enter__ and __exit__ for resource management. While not traditional method chaining, they enable context chaining patterns:

Nested with statements (Python 3.1+ single line)
ExitStack for dynamic context management
__enter__ returning self for method chaining within the context

`enter` returning self:

When __enter__ returns self, you can chain methods on the context variable that's also the manager.

Pseudo Code

# __enter__ returns self for chaining
with Resource().configure(x=1) as r:
    r.do_something()
# __exit__ handles cleanup

# Multiple contexts in one with
with open('a') as f1, open('b') as f2:
    ...

# ExitStack for dynamic contexts
with ExitStack() as stack:
    files = [stack.enter_context(open(f)) for f in filenames]

Code

from contextlib import contextmanager, ExitStack

# Context manager with chainable configuration
class Connection:
    def __init__(self, host='localhost'):
        self.host = host
        self._timeout = 30
        self._retries = 3
        self._connected = False

    def timeout(self, seconds):
        self._timeout = seconds
        return self  # chainable

    def retries(self, count):
        self._retries = count
        return self  # chainable

    def __enter__(self):
        print(f"Connecting to {self.host} (timeout={self._timeout}s, retries={self._retries})")
        self._connected = True
        return self  # return self for use in 'as' clause

    def __exit__(self, exc_type, exc_val, exc_tb):
        print(f"Disconnecting from {self.host}")
        self._connected = False
        return False  # don't suppress exceptions

    def query(self, sql):
        if not self._connected:
            raise RuntimeError("Not connected")
        print(f"Executing: {sql}")
        return [{"id": 1}]

# Chain configuration BEFORE entering context
with Connection('db.example.com').timeout(10).retries(5) as conn:
    results = conn.query('SELECT * FROM users')
    print(results)
# Disconnecting happens automatically

# Multiple context managers (Python 3.1+)
with open('/dev/null', 'w') as f1, open('/dev/null', 'w') as f2:
    f1.write('hello')
    f2.write('world')

# Python 3.10+ parenthesized context managers
# with (
#     open('file1') as f1,
#     open('file2') as f2,
#     open('file3') as f3,
# ):
#     ...

# ExitStack for dynamic number of context managers
def process_files(filenames):
    with ExitStack() as stack:
        files = [stack.enter_context(open(f, 'w')) for f in filenames]
        for i, f in enumerate(files):
            f.write(f'Content for file {i}')
    # All files closed automatically

# Chainable context manager with contextlib
@contextmanager
def timer(label=''):
    import time
    start = time.perf_counter()
    yield
    elapsed = time.perf_counter() - start
    print(f"{label}: {elapsed:.4f}s")

with timer('database query'):
    # simulated work
    pass

# Nested context managers as chain
class TransactionManager:
    def __init__(self, db):
        self.db = db
        self._savepoints = []

    def __enter__(self):
        self._savepoints.append(f'sp_{len(self._savepoints)}')
        print(f"BEGIN {self._savepoints[-1]}")
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        sp = self._savepoints.pop()
        if exc_type:
            print(f"ROLLBACK {sp}")
        else:
            print(f"COMMIT {sp}")
        return False

Connecting to db.example.com (timeout=10s, retries=5)
Executing: SELECT * FROM users
[{'id': 1}]
Disconnecting from db.example.com
database query: 0.0001s  (varies)

Key Points

•__enter__ returning self enables chaining within the context block
•Configure with chained methods before entering the context
•ExitStack handles dynamic numbers of context managers
•Python 3.10+ supports parenthesized multi-line context managers

Gotchas

•__enter__ must return the object you want in 'as' clause (usually self)
•__exit__ returning True suppresses exceptions -- usually return False
•Chaining .method() BEFORE 'with' means __enter__ runs on the modified object
•ExitStack cleanup happens in LIFO order (last entered, first exited)

__enter__ returning self lets you chain methods before with. ExitStack manages dynamic context managers. Python 3.10+ supports parenthesized multi-line with.

•Chain config before 'with'; __enter__ returns self
•ExitStack for dynamic context management

class DB:
    def timeout(self, n):
        self._timeout = n
        return self
    def __enter__(self):
        print('connected')
        return self
    def __exit__(self, *args):
        print('disconnected')

with DB().timeout(10) as db:
    pass  # connected, then disconnected

connected
disconnected

__exit__ returning True suppresses exceptions

Question 8 / 12

What is the pipe pattern and how does it relate to method chaining?

The pipe pattern passes data through a sequence of functions, where each function's output becomes the next function's input. It is an alternative to method chaining when you don't control the class.

Method chaining vs Pipe:

Method chaining: obj.method1().method2().method3()
Pipe: pipe(data, func1, func2, func3)

Advantages of pipe:

Works with any function (no need to modify classes)
Composable with existing functions
Functional programming style

Pandas provides .pipe() method. Python has no built-in pipe operator (unlike Elixir's |> or F#'s |>).

Pseudo Code

# Pipe pattern
result = pipe(data,
    clean_data,
    validate,
    transform,
    save
)

# Equivalent to:
result = save(transform(validate(clean_data(data))))
# But pipe reads top-to-bottom, nested reads inside-out

Code

from functools import reduce
from typing import Callable, TypeVar, Any

T = TypeVar('T')

# Simple pipe function
def pipe(value, *functions):
    """Pass value through a sequence of functions."""
    return reduce(lambda v, f: f(v), functions, value)

# Usage
def double(x):
    return x * 2

def add_ten(x):
    return x + 10

def to_string(x):
    return f"Result: {x}"

result = pipe(5, double, add_ten, to_string)
print(result)  # "Result: 20"

# Compared to nested calls (reads inside-out)
result = to_string(add_ten(double(5)))
print(result)  # "Result: 20" -- same but harder to read

# Data processing pipeline
def strip_whitespace(text):
    return text.strip()

def lowercase(text):
    return text.lower()

def remove_punctuation(text):
    import string
    return text.translate(str.maketrans('', '', string.punctuation))

def split_words(text):
    return text.split()

words = pipe(
    "  Hello, World! This is a TEST.  ",
    strip_whitespace,
    lowercase,
    remove_punctuation,
    split_words
)
print(words)  # ['hello', 'world', 'this', 'is', 'a', 'test']

# Pipe with lambdas for parameterized functions
from functools import partial

def filter_by(items, predicate):
    return [x for x in items if predicate(x)]

def sort_by(items, key=None, reverse=False):
    return sorted(items, key=key, reverse=reverse)

def take(items, n):
    return items[:n]

numbers = [3, 1, 4, 1, 5, 9, 2, 6, 5, 3, 5]

result = pipe(
    numbers,
    lambda x: filter_by(x, lambda n: n > 2),
    lambda x: sort_by(x, reverse=True),
    lambda x: take(x, 5),
)
print(result)  # [9, 6, 5, 5, 5]

# Using partial for cleaner syntax
result = pipe(
    numbers,
    partial(filter_by, predicate=lambda n: n > 2),
    partial(sort_by, reverse=True),
    partial(take, n=5),
)
print(result)  # [9, 6, 5, 5, 5]

# Composing functions (create reusable pipeline)
def compose(*functions):
    """Create a function that applies functions right-to-left."""
    return reduce(lambda f, g: lambda x: f(g(x)), functions)

process_text = compose(split_words, remove_punctuation, lowercase, strip_whitespace)
result = process_text("  Hello, World!  ")
print(result)  # ['hello', 'world']

# Pipeline class for OOP style
class Pipeline:
    def __init__(self, value):
        self._value = value

    def pipe(self, func, *args, **kwargs):
        self._value = func(self._value, *args, **kwargs)
        return self

    @property
    def value(self):
        return self._value

result = (Pipeline("  Hello World!  ")
    .pipe(str.strip)
    .pipe(str.lower)
    .pipe(str.replace, 'world', 'python')
    .value)
print(result)  # 'hello python!'

Result: 20
Result: 20
['hello', 'world', 'this', 'is', 'a', 'test']
[9, 6, 5, 5, 5]
[9, 6, 5, 5, 5]
['hello', 'world']
hello python!

Key Points

•Pipe passes data through a sequence of functions (output -> input)
•Reads top-to-bottom unlike nested calls (inside-out)
•Works with any function -- no need to modify classes
•Use functools.partial for parameterized functions in pipes

Gotchas

•Python has no built-in pipe operator -- must use a function or library
•Error messages in pipes can be unclear (which step failed?)
•Lambdas in pipes reduce readability -- prefer named functions or partial()
•compose() applies right-to-left; pipe() applies left-to-right -- don't mix them up

Pipe passes data through functions sequentially: pipe(data, f1, f2, f3). Reads top-to-bottom (unlike nested f3(f2(f1(data)))). Works with any function, no class modification needed.

•Sequential function application, left to right
•Alternative to method chaining for standalone functions

from functools import reduce

def pipe(value, *fns):
    return reduce(lambda v, f: f(v), fns, value)

result = pipe(5, lambda x: x*2, lambda x: x+10, str)
print(result)  # '20'

Python has no built-in pipe operator

Question 9 / 12

How do you implement method chaining with type hints for IDE support?

Proper type hints on chained methods are crucial for IDE autocomplete and type checking. The key challenge is: how do you type return self so that subclasses work correctly?

Approaches:

String annotation: -> 'ClassName'
from __future__ import annotations: Deferred evaluation
typing.Self (Python 3.11+): Correctly types self in subclasses
TypeVar bound to class: Works before 3.11

typing.Self is the best solution for method chaining because it correctly represents that the return type matches the actual class (important for inheritance).

Pseudo Code

# Python 3.11+
from typing import Self

class Base:
    def method(self) -> Self:  # returns actual type, not just Base
        return self

class Child(Base):
    pass

child = Child().method()  # type is Child, not Base

Code

from __future__ import annotations
from typing import TypeVar

# Approach 1: String annotation (works everywhere)
class QueryV1:
    def filter(self, condition: str) -> 'QueryV1':
        return self

    def limit(self, n: int) -> 'QueryV1':
        return self

# Approach 2: TypeVar for inheritance support (pre-3.11)
T = TypeVar('T', bound='QueryV2')

class QueryV2:
    def filter(self: T, condition: str) -> T:
        return self

    def limit(self: T, n: int) -> T:
        return self

class SpecialQuery(QueryV2):
    def special_method(self) -> 'SpecialQuery':
        return self

# With TypeVar, IDE knows this returns SpecialQuery, not QueryV2
sq = SpecialQuery().filter('x=1')  # type: SpecialQuery
sq.special_method()  # works! IDE knows it's SpecialQuery

# Approach 3: typing.Self (Python 3.11+)
# from typing import Self
#
# class QueryV3:
#     def filter(self, condition: str) -> Self:
#         return self
#     def limit(self, n: int) -> Self:
#         return self
#
# class SpecialQuery(QueryV3):
#     def special(self) -> Self:
#         return self
#
# sq = SpecialQuery().filter('x').special()  # type: SpecialQuery

# Full example with proper typing
class HTMLBuilder:
    def __init__(self) -> None:
        self._tag: str = 'div'
        self._classes: list[str] = []
        self._attrs: dict[str, str] = {}
        self._children: list[str] = []

    def tag(self: T, tag: str) -> T:
        self._tag = tag
        return self

    def add_class(self: T, cls: str) -> T:
        self._classes.append(cls)
        return self

    def attr(self: T, key: str, value: str) -> T:
        self._attrs[key] = value
        return self

    def child(self: T, content: str) -> T:
        self._children.append(content)
        return self

    def build(self) -> str:
        classes = f' class="{" ".join(self._classes)}"' if self._classes else ''
        attrs = ''.join(f' {k}="{v}"' for k, v in self._attrs.items())
        children = ''.join(self._children)
        return f'<{self._tag}{classes}{attrs}>{children}</{self._tag}>'

# IDE autocomplete works on every chained call
html = (HTMLBuilder()
    .tag('section')
    .add_class('container')
    .add_class('main')
    .attr('id', 'content')
    .child('<h1>Hello</h1>')
    .child('<p>World</p>')
    .build())

print(html)
# <section class="container main" id="content"><h1>Hello</h1><p>World</p></section>

<section class="container main" id="content"><h1>Hello</h1><p>World</p></section>

Key Points

•typing.Self (3.11+) is the best solution for chained method return types
•TypeVar bound to the class works for pre-3.11 with proper inheritance support
•String annotations ('ClassName') work but don't handle subclasses correctly
•Proper types enable IDE autocomplete on every chained call

Gotchas

•String annotation -> 'ClassName' doesn't work with inheritance (always returns base type)
•TypeVar approach requires annotating self parameter explicitly: def method(self: T) -> T
•from __future__ import annotations changes all annotations to strings (deferred evaluation)
•mypy may need plugins or configuration for complex chaining patterns

Use typing.Self (3.11+) or TypeVar bound to the class for chained method return types. Enables IDE autocomplete and correct types through inheritance.

•Self (3.11+) or TypeVar for correct subclass return types
•Enables IDE autocomplete through the chain

from typing import TypeVar

T = TypeVar('T', bound='Builder')

class Builder:
    def set(self: T, key: str, val: str) -> T:
        return self  # returns actual type in subclasses

class SpecialBuilder(Builder):
    def extra(self) -> 'SpecialBuilder':
        return self

# IDE knows this is SpecialBuilder, not Builder
SpecialBuilder().set('a', '1').extra()

String annotations don't handle inheritance correctly

Question 10 / 12

How do you handle errors in method chains?

Error handling in method chains is tricky because errors can occur at any step, and the chain makes it hard to identify which step failed.

Strategies:

Fail at terminal: Collect errors during chaining, raise at .build()/.execute()
Fail fast: Raise immediately when a method receives invalid input
Result type: Return a Result/Either object that carries success or error
Try/except around the chain: Catch and add context
Logging in each step: For debugging long chains

Pseudo Code

# Strategy 1: Collect errors, fail at terminal
result = (Builder()
    .name('')      # stores error: 'name is required'
    .email('bad')  # stores error: 'invalid email'
    .build())      # raises ValidationError with all errors

# Strategy 3: Result type
result = (Pipeline(data)
    .map(parse)    # returns Result.ok or Result.error
    .map(validate) # skips if previous was error
    .map(save))    # skips if previous was error

Code

from typing import Optional, List, Any

# Strategy 1: Collect errors, fail at terminal
class FormBuilder:
    def __init__(self):
        self._data = {}
        self._errors: List[str] = []

    def field(self, name: str, value: Any, required: bool = False):
        if required and (value is None or value == ''):
            self._errors.append(f'{name} is required')
        else:
            self._data[name] = value
        return self

    def validate_email(self, field: str):
        value = self._data.get(field, '')
        if value and '@' not in value:
            self._errors.append(f'{field} is not a valid email')
        return self

    def build(self) -> dict:
        if self._errors:
            raise ValueError(f"Validation errors: {'; '.join(self._errors)}")
        return self._data

    @property
    def errors(self) -> List[str]:
        return self._errors

# Usage
try:
    result = (FormBuilder()
        .field('name', '', required=True)
        .field('email', 'bad-email', required=True)
        .validate_email('email')
        .build())
except ValueError as e:
    print(e)  # Validation errors: name is required; email is not a valid email

# Strategy 2: Result type (monadic error handling)
class Result:
    def __init__(self, value=None, error=None):
        self._value = value
        self._error = error

    @staticmethod
    def ok(value):
        return Result(value=value)

    @staticmethod
    def fail(error):
        return Result(error=error)

    @property
    def is_ok(self):
        return self._error is None

    @property
    def value(self):
        if not self.is_ok:
            raise ValueError(f"Cannot get value from error result: {self._error}")
        return self._value

    @property
    def error(self):
        return self._error

    def map(self, func):
        """Apply func if ok, skip if error."""
        if not self.is_ok:
            return self  # propagate error
        try:
            return Result.ok(func(self._value))
        except Exception as e:
            return Result.fail(str(e))

    def flat_map(self, func):
        """Apply func that returns Result."""
        if not self.is_ok:
            return self
        return func(self._value)

# Usage: errors propagate through the chain
def parse_int(s):
    return int(s)

def double(n):
    return n * 2

def check_positive(n):
    if n <= 0:
        raise ValueError('Must be positive')
    return n

# Success case
result = Result.ok('42').map(parse_int).map(check_positive).map(double)
print(f"Success: {result.value}")  # 84

# Error case -- error propagates, later steps skipped
result = Result.ok('abc').map(parse_int).map(check_positive).map(double)
print(f"Error: {result.error}")  # "invalid literal for int()..."

# Error in middle -- later steps skipped
result = Result.ok('-5').map(parse_int).map(check_positive).map(double)
print(f"Error: {result.error}")  # "Must be positive"

# Strategy 3: Debug helper for long chains
def debug(label=''):
    def _debug(value):
        print(f"[{label}] {type(value).__name__}: {value!r}")
        return value
    return _debug

result = (Result.ok('  42  ')
    .map(str.strip)
    .map(debug('after strip'))   # prints for debugging
    .map(parse_int)
    .map(debug('after parse'))   # prints for debugging
    .map(double))
print(result.value)  # 84

Validation errors: name is required; email is not a valid email
Success: 84
Error: invalid literal for int() with base 10: 'abc'
Error: Must be positive
[after strip] str: '42'
[after parse] int: 42
84

Key Points

•Collect errors during chain, raise at terminal (build/execute)
•Result type propagates errors through the chain, skipping subsequent steps
•Debug helpers (print intermediate values) help diagnose chain failures
•try/except around the entire chain catches errors from any step

Gotchas

•Raising immediately in a chain gives poor error messages (no context about which step)
•Collecting errors means invalid state may accumulate -- validate early for critical errors
•Result type adds complexity -- use only when error propagation is genuinely needed
•Long chains with no intermediate variables make stack traces harder to read

Three strategies: (1) collect errors, fail at terminal; (2) Result type that propagates errors and skips subsequent steps; (3) debug helpers to log intermediate values.

•Result type skips remaining chain on error
•Collect errors, fail at terminal for validation

class Result:
    def __init__(self, value=None, error=None):
        self.value, self.error = value, error
        self.is_ok = error is None
    def map(self, func):
        if not self.is_ok:
            return self  # skip on error
        try:
            return Result(value=func(self.value))
        except Exception as e:
            return Result(error=str(e))

result = Result(value='42').map(int).map(lambda x: x*2)
print(result.value)  # 84

Long chains make stack traces harder to read

Question 11 / 12

What are real-world examples of method chaining in Python libraries?

Method chaining is pervasive in Python's most popular libraries. Understanding these patterns helps you use them effectively and design your own APIs.

Popular examples:

Django QuerySets: Immutable chaining for database queries
pandas DataFrames: Data transformation pipelines
SQLAlchemy: ORM query building
requests (PreparedRequest): HTTP request building
Python strings: Built-in string methods
pathlib.Path: File path manipulation
BeautifulSoup: HTML/XML parsing
Matplotlib: Plot configuration

Pseudo Code

Django:     User.objects.filter(...).exclude(...).order_by(...).values(...)
pandas:     df.dropna().groupby('col').mean().reset_index()
SQLAlchemy: session.query(User).filter(...).order_by(...).limit(10)
pathlib:    Path('/home') / 'user' / 'docs'  (operator chaining)
strings:    '  hello  '.strip().upper().replace('H', 'J')

Code

# 1. Python strings (immutable chaining)
result = '  Hello, World!  '.strip().lower().replace('world', 'python').title()
print(result)  # 'Hello, Python!'

# 2. pathlib.Path (operator chaining with /)
from pathlib import Path

config = Path.home() / '.config' / 'myapp' / 'settings.json'
print(config)  # /home/user/.config/myapp/settings.json

# Method chaining on Path
result = Path('/tmp/data.txt').with_suffix('.csv').with_name('output.csv')
print(result)  # /tmp/output.csv

# 3. Django QuerySets (immutable chaining)
# users = (User.objects
#     .filter(is_active=True)
#     .exclude(role='banned')
#     .select_related('profile')
#     .order_by('-date_joined')
#     .values('username', 'email')
#     [:20])

# 4. requests library
import requests

# Session with chained configuration
# session = requests.Session()
# response = (session
#     .get('https://api.example.com/data',
#          headers={'Authorization': 'Bearer token'},
#          params={'page': 1})
#     .json())

# 5. Python's decimal module
from decimal import Decimal
result = Decimal('3.14159').quantize(Decimal('0.01'))  # 3.14

# 6. itertools chaining pattern
from itertools import chain, islice
result = list(islice(chain([1,2], [3,4], [5,6]), 4))
print(result)  # [1, 2, 3, 4]

# 7. Regular expressions
import re
# Compile + chain operations
pattern = re.compile(r'\d+')
matches = pattern.findall('abc 123 def 456')
print(matches)  # ['123', '456']

# 8. Built-in functional tools
numbers = range(100)
result = list(
    filter(lambda x: x % 3 == 0,
    map(lambda x: x ** 2,
    filter(lambda x: x % 2 == 0,
    numbers)))
)
# Better with comprehension:
result = [x**2 for x in range(100) if x % 2 == 0 if x**2 % 3 == 0]

# 9. datetime chaining
from datetime import datetime, timedelta
future = (datetime.now()
    .replace(hour=0, minute=0, second=0, microsecond=0)
    + timedelta(days=7))
print(future.strftime('%Y-%m-%d'))  # next week's date

# 10. Custom chainable config
class AppConfig:
    def __init__(self):
        self._config = {}

    def set(self, key, value):
        self._config[key] = value
        return self

    def from_env(self, key, env_var, default=None):
        import os
        self._config[key] = os.environ.get(env_var, default)
        return self

    def build(self):
        return dict(self._config)

config = (AppConfig()
    .set('debug', True)
    .set('port', 8080)
    .from_env('secret', 'SECRET_KEY', 'dev-secret')
    .from_env('db_url', 'DATABASE_URL', 'sqlite:///app.db')
    .build())
print(config)

Hello, Python!
/home/user/.config/myapp/settings.json
/tmp/output.csv
[1, 2, 3, 4]
['123', '456']
2026-01-08
{'debug': True, 'port': 8080, 'secret': 'dev-secret', 'db_url': 'sqlite:///app.db'}

Key Points

•Django QuerySets, pandas DataFrames, SQLAlchemy all use immutable chaining
•Python strings and pathlib.Path are built-in examples of chaining
•Most libraries return new objects (immutable style) for safety
•Operator overloading (pathlib's /) is another form of chaining

Gotchas

•Not all methods are chainable -- list.sort(), dict.update() return None
•Mixing chainable and non-chainable methods breaks the chain silently
•Some library methods have inplace=True options that return None (pandas)
•String methods create new strings each time -- O(n) per operation, can be slow in loops

Real-world chaining: Django QuerySets, pandas DataFrames, SQLAlchemy queries, pathlib.Path, Python strings. Most use immutable style (return new objects). Check if a method returns None before chaining.

•Strings, pathlib, Django, pandas all support chaining
•Most return new objects (immutable style)

# Strings
result = '  hello world  '.strip().title().replace(' ', '_')

# pathlib
from pathlib import Path
path = Path.home() / 'docs' / 'file.txt'

# Django-style
# User.objects.filter(active=True).order_by('name')[:10]

list.sort() returns None -- not chainable

Question 12 / 12

How do you implement command chaining for undo/redo functionality?

The Command pattern encapsulates operations as objects, enabling undo/redo, logging, and transaction-like behavior. Combined with chaining, you can build a history of operations that can be replayed, undone, or serialized.

Components:

Command: Object with execute() and undo() methods
CommandHistory: Stack of executed commands
Chainable API: Returns the history object for method chaining

Use cases:

Text editors (undo/redo)
Database transactions
Drawing applications
Configuration systems with rollback

Pseudo Code

history = (CommandHistory(document)
    .execute(InsertText('Hello'))
    .execute(InsertText(' World'))
    .execute(MakeBold())
    .undo()      # undo MakeBold
    .undo()      # undo InsertText(' World')
    .redo())     # redo InsertText(' World')

Code

from abc import ABC, abstractmethod
from typing import Any

# Command interface
class Command(ABC):
    @abstractmethod
    def execute(self) -> None:
        pass

    @abstractmethod
    def undo(self) -> None:
        pass

    @abstractmethod
    def description(self) -> str:
        pass

# Concrete commands
class SetValueCommand(Command):
    def __init__(self, document: dict, key: str, value: Any):
        self._doc = document
        self._key = key
        self._new_value = value
        self._old_value = document.get(key)

    def execute(self):
        self._old_value = self._doc.get(self._key)
        self._doc[self._key] = self._new_value

    def undo(self):
        if self._old_value is None:
            self._doc.pop(self._key, None)
        else:
            self._doc[self._key] = self._old_value

    def description(self):
        return f"Set {self._key} = {self._new_value!r}"

class DeleteKeyCommand(Command):
    def __init__(self, document: dict, key: str):
        self._doc = document
        self._key = key
        self._old_value = None

    def execute(self):
        self._old_value = self._doc.pop(self._key, None)

    def undo(self):
        if self._old_value is not None:
            self._doc[self._key] = self._old_value

    def description(self):
        return f"Delete {self._key}"

# Command history with chainable API
class CommandHistory:
    def __init__(self, target: dict):
        self._target = target
        self._history: list[Command] = []
        self._redo_stack: list[Command] = []

    def set(self, key: str, value: Any) -> 'CommandHistory':
        cmd = SetValueCommand(self._target, key, value)
        cmd.execute()
        self._history.append(cmd)
        self._redo_stack.clear()  # clear redo after new action
        return self

    def delete(self, key: str) -> 'CommandHistory':
        cmd = DeleteKeyCommand(self._target, key)
        cmd.execute()
        self._history.append(cmd)
        self._redo_stack.clear()
        return self

    def undo(self) -> 'CommandHistory':
        if not self._history:
            print("Nothing to undo")
            return self
        cmd = self._history.pop()
        cmd.undo()
        self._redo_stack.append(cmd)
        print(f"Undo: {cmd.description()}")
        return self

    def redo(self) -> 'CommandHistory':
        if not self._redo_stack:
            print("Nothing to redo")
            return self
        cmd = self._redo_stack.pop()
        cmd.execute()
        self._history.append(cmd)
        print(f"Redo: {cmd.description()}")
        return self

    def show_history(self) -> 'CommandHistory':
        print("History:")
        for i, cmd in enumerate(self._history, 1):
            print(f"  {i}. {cmd.description()}")
        return self

    @property
    def state(self) -> dict:
        return dict(self._target)

# Usage with chaining
doc = {}
result = (CommandHistory(doc)
    .set('name', 'Alice')
    .set('email', 'alice@example.com')
    .set('role', 'admin')
    .show_history()
    .undo()            # undo role=admin
    .undo()            # undo email
    .show_history()
    .redo()            # redo email
    .set('age', 30)
    .show_history())

print(f"Final state: {result.state}")
# {'name': 'Alice', 'email': 'alice@example.com', 'age': 30}

# Batch operations
print("\n--- Batch undo ---")
(CommandHistory({'x': 1})
    .set('a', 10)
    .set('b', 20)
    .set('c', 30)
    .undo()
    .undo()
    .undo())

History:
1. Set name = 'Alice'
2. Set email = 'alice@example.com'
3. Set role = 'admin'
Undo: Set role = 'admin'
Undo: Set email = 'alice@example.com'
History:
1. Set name = 'Alice'
Redo: Set email = 'alice@example.com'
History:
1. Set name = 'Alice'
2. Set email = 'alice@example.com'
3. Set age = 30
Final state: {'name': 'Alice', 'email': 'alice@example.com', 'age': 30}

--- Batch undo ---
Undo: Set c = 30
Undo: Set b = 20
Undo: Set a = 10

Key Points

•Commands encapsulate execute() and undo() as objects
•History stack enables unlimited undo; redo stack for redo
•New actions clear the redo stack (standard undo/redo behavior)
•Chainable API makes building and manipulating command sequences natural

Gotchas

•Commands must store enough state to fully reverse their operation
•Redo stack must be cleared when a new command is executed after undoing
•Complex undo (e.g., file operations) may need deep copies of state
•Memory grows with history -- consider limiting history size for long-running apps

Command pattern: encapsulate operations with execute() and undo(). History stack enables undo/redo. Chainable API: .set(k,v).delete(k).undo().redo() all return self.

•Commands store execute + undo logic
•History stack enables chained undo/redo

class History:
    def __init__(self):
        self._stack = []
    def do(self, action, undo_action):
        action()
        self._stack.append(undo_action)
        return self
    def undo(self):
        if self._stack:
            self._stack.pop()()
        return self

Commands must store enough state to reverse the operation

Built by onllm.dev

Home GitHub Support awesomePrep

What is method chaining and how does it work in Python?

How it works:

Two flavors:

Real-world examples:

How do you implement the Builder pattern with method chaining in Python?

Benefits:

How does pandas-style method chaining work and why is it powerful?

Why it works:

The pipe() method:

How does SQLAlchemy query chaining work?

Key chainable methods:

How do you design a chainable API class in Python?

Design principles:

Terminal vs non-terminal methods:

What is immutable chaining and how does it differ from mutable chaining?

Mutable chaining

Immutable chaining

When to use each:

How do __enter__ and __exit__ enable context manager chaining?

__enter__ returning self:

What is the pipe pattern and how does it relate to method chaining?

Method chaining vs Pipe:

Advantages of pipe:

How do you implement method chaining with type hints for IDE support?

Approaches:

How do you handle errors in method chains?

Strategies:

What are real-world examples of method chaining in Python libraries?

Popular examples:

How do you implement command chaining for undo/redo functionality?

Components:

Use cases:

Method Chaining & Fluent Interfaces

The `pipe()` method:

How do enter and exit enable context manager chaining?

`enter` returning self: