Advanced & Dynamic Python Mechanics

What this track is orientation

Eight parts covering the advanced engineering behind real AI systems: A1 dynamic mechanics → A2 memory & the GIL → A3 async & streaming → A4 numerical & tensors → A5 strings & tokenization → A6 validation & resiliency → A7 vector DBs & frameworks → A8 MLOps. Each is standalone; take them in any order. Everything is grounded in real agent scenarios.

1 · Python's object model — the foundation advanced

Here's a bug that has cost more than one team a bad afternoon. Someone writes a base class with cache = {} at the class level, meaning it as a per-object default. Every instance quietly shares the same dictionary, so a value cached by one request leaks into another. The code looks obviously correct; it fails in the most confusing way possible. The fix isn't a trick — it's understanding where Python actually stores attributes and in what order it looks for them. Get the object model right and a whole category of "how is that even possible" bugs simply stops happening.

The mental model that unlocks everything: in Python, the dot in obj.x is not a memory read — it's a little search algorithm. Picture asking for a book. You first check your own desk (the instance's own storage), and only if it's not there do you walk to the shared library shelf (the class, then its parents). Two objects of the same class each have their own desk but share one library. That's why the cache = {} bug bites — the dictionary sat on the shared shelf, not on each desk, so everyone scribbled in the same copy.

The common mistake is assuming an attribute "belongs to the object" just because you read it through the object. You can read c.debug perfectly happily even when debug lives on the class — Python transparently falls back to the shelf. The gap only shows up when you write: assigning c.debug = True creates a brand-new copy on that one instance's desk, shadowing the shared one, while everyone else still sees the original. Reads look through the whole chain; writes land on the instance. Holding those two rules in your head separately is most of the battle.

Everything in Python is an object with a type, and attribute access (obj.x) is not a primitive — it's a protocol you can hook into. Understanding the lookup order is what makes the rest of this page make sense.

python# obj.x resolves in this order:
#   1. data descriptors on type(obj)        (e.g. @property)
#   2. obj.__dict__['x']                     (instance attributes)
#   3. non-data descriptors / class attrs on type(obj) and its MRO
#   4. type(obj).__getattr__('x')            (fallback hook)
#   -> AttributeError if all fail

class Config:
    debug = False              # class attribute (shared)
    def __init__(self):
        self.name = "agent"     # instance attribute (per-object)

c = Config()
print(c.name)                  # found in c.__dict__
print(c.debug)                 # not in instance -> found on the class
print(type(c).__mro__)         # the lookup path: (Config, object)

2 · __getattr__ — proxies, lazy loaders, config objects advanced

You've almost certainly used __getattr__ without knowing it. Every time you write settings.database.host against a config library, or an SDK client that "connects on first use," or a mock in a test that answers to any method name you throw at it — something is intercepting an attribute that was never actually defined and conjuring it on the spot. That something is usually __getattr__. It's one of the highest-leverage hooks in the language: a handful of lines turns a plain object into a proxy, a lazy loader, or a friendly view over a nested dict.

The intuition to hold onto is "the fallback that only fires when the normal search comes up empty." Think of a receptionist who only picks up the phone when nobody at the requested desk answers. If the attribute genuinely exists on the instance or its class, Python hands it back directly and __getattr__ never runs. It's summoned only for the misses — which is exactly what makes it safe and cheap: real attributes stay fast, and you get a single place to decide what a missing name should mean (fetch it from a dict, build a remote proxy, or raise).

Here's the mistake that trips everyone, and it's worth stating before you write a line: do not confuse __getattr__ with __getattribute__. The near-identical name hides a huge difference. __getattribute__ intercepts every access, including the ones you make inside your own hook — so a naïve return self._data[name] re-triggers the interceptor on self._data, which re-triggers it, and you get infinite recursion and a blown stack. __getattr__ sidesteps the whole trap because it only runs on misses; reaching for your backing store (a real attribute) doesn't re-enter it. Reach for __getattr__ in 99% of cases and leave __getattribute__ for the rare occasion you truly must see every read.

__getattr__ is called only when normal lookup fails. It's the hook behind config objects that read from a dict, lazy-loading heavy resources, and proxy objects that forward to a remote service. (Its cousin __getattribute__ intercepts every access — powerful but easy to make infinitely recursive; rarely needed.)

pythonclass DotConfig:
    def __init__(self, data):
        self._data = data
    def __getattr__(self, key):        # only for missing attrs
        try:
            v = self._data[key]
        except KeyError:
            raise AttributeError(key) from None
        return DotConfig(v) if isinstance(v, dict) else v

cfg = DotConfig({"model": "claude-opus-4-8", "limits": {"rpm": 50}})
print(cfg.model)               # 'claude-opus-4-8'
print(cfg.limits.rpm)          # 50 — nested access "just works"

class LazyClient:
    def __init__(self):
        self._real = None
    def __getattr__(self, name):
        if self._real is None:
            print("... connecting on first use")
            self._real = {"messages": lambda: "resp"}   # stand-in for a heavy SDK client
        return self._real[name]

3 · __call__ — objects that behave like functions intermediate → advanced

Picture the moment your "simple function" needs to remember something. You wrote a rate limiter as a plain function; now it needs to track when it last fired. You wrote a tool call as a function; now it needs to count invocations for the audit log. The lazy reach is a global variable — and globals are how a codebase slowly rots: two callers share state they didn't know they shared, tests can't isolate, and nobody can tell what the function actually depends on. __call__ is the clean escape: keep the ergonomics of "just call it with parentheses," but give it a private memory that travels with the object.

The everyday analogy is a vending machine versus a hand-crank. A bare function is a hand-crank: you turn it, it does its one thing, it forgets you the instant it's done. A callable object is a vending machine — you still just press a button (the parentheses), but behind the panel it's tracking stock, counting sales, holding your configuration. Same interface for the caller; a real interior with state for the author. The __call__ method is the button: define it, and Python lets you write obj(...) even though obj is not a function.

Why prefer this over a closure, which can also carry state? Two reasons that matter in real systems. First, introspection: an object can expose its state as ordinary attributes (tool.calls, limiter.remaining) that you can read, log, and assert on in tests — a closure hides its captured variables where you can't reach them. Second, configurability: an object naturally grows methods (reset(), describe()) and can be re-parameterized without rebuilding it. The common mistake is over-reaching the other way — using a heavyweight class where a two-line closure would do. The rule of thumb: if the "function" needs inspectable state, extra methods, or a name in an error message, make it a callable object; otherwise a closure is fine.

Implement __call__ and an instance becomes callable like a function — but with state. This is the clean way to build configurable, stateful "functions": a rate limiter, a retry policy, a tool with bound config.

pythonclass Tool:
    def __init__(self, name, fn, calls=0):
        self.name, self.fn, self.calls = name, fn, calls
    def __call__(self, **kwargs):     # the instance is callable
        self.calls += 1               # ... and remembers state across calls
        return self.fn(**kwargs)

scale = Tool("scale", lambda replicas: f"scaled to {replicas}")
print(scale(replicas=3))         # 'scaled to 3'
print(scale.calls)              # 1 — state persists, unlike a bare function

4 · Descriptors — the magic behind @property, ORM fields, Pydantic expert intermediate

Imagine you have ten config fields that all need the same guard. temperature, top_p, and half a dozen others must each sit between 0 and 1. The copy-paste answer is ten @property getters and ten setters that all say the same "is it in range?" thing — a hundred lines of near-identical validation that someone will eventually update in nine places out of ten and introduce a silent bug. Descriptors exist precisely to kill that duplication: write the "bounded field" logic once, then declare temperature = Bounded(0, 1) as a one-liner on each field. This isn't an academic curiosity; it's the single idea that makes Pydantic, SQLAlchemy, and Django's field systems possible.

The analogy that makes it click: a descriptor is a reusable smart doorbell you install on a field. A plain attribute is a doorway anyone walks through unchecked. A descriptor puts a small device on that doorway — __get__ fires whenever someone reads the field, __set__ whenever someone writes it — and because the device is its own object, you can hang the identical device on as many doorways (fields, classes) as you like. @property is the same idea but welded to one specific doorway; a descriptor is the device sold separately, so it's shareable.

The mechanic that surprises people, and the mistake to avoid: a descriptor is stored on the class, once, yet it must hold a different value for each instance. If you naïvely stash the value on self (the descriptor object) instead of on the instance being written to, all your objects share one value — the same shared-state trap from §1, now hiding inside your abstraction. The disciplined fix is __set_name__, which Python calls at class-definition time to tell the descriptor which attribute name it was bound to; the descriptor then keeps each instance's value on that instance under a private key. Once you see __get__/__set__/__set_name__ working together, @property, classmethod, ORM columns, and Pydantic fields all stop being magic and become the same pattern wearing different hats.

A descriptor is an object that defines __get__/__set__; when it's a class attribute, those methods intercept access to it on instances. This is the mechanism behind @property, classmethod, ORM columns, and Pydantic/dataclass fields. Build one and you understand all of them.

pythonclass Bounded:
    """A reusable field that validates its range on every assignment."""
    def __init__(self, lo, hi):
        self.lo, self.hi = lo, hi
    def __set_name__(self, owner, name):   # Python tells us our attribute name
        self.attr = "_" + name
    def __get__(self, obj, objtype=None):
        if obj is None: return self
        return getattr(obj, self.attr)
    def __set__(self, obj, value):
        if not (self.lo <= value <= self.hi):
            raise ValueError(f"{value} not in [{self.lo}, {self.hi}]")
        setattr(obj, self.attr, value)

class GenConfig:
    temperature = Bounded(0.0, 1.0)      # the descriptor guards this field
    top_p = Bounded(0.0, 1.0)
    def __init__(self, temperature, top_p):
        self.temperature = temperature       # -> validated via __set__
        self.top_p = top_p

GenConfig(0.7, 0.9)                    # ok
# GenConfig(2.0, 0.9)  -> ValueError: 2.0 not in [0.0, 1.0]

5 · Stateful & parameterized decorators advanced

Every real agent tool eventually sprouts the same three chores: retry it on a flaky network, time it for the dashboard, log it for the audit trail. If you paste those chores into each tool, you now maintain the retry logic in twenty places and the day the backoff policy changes you'll miss one. Decorators are how you write the chore once and wrap it around any function — the classic "cross-cutting concern" that has nothing to do with the tool's real job but has to happen anyway. This section is the production form: decorators that take arguments (@retry(times=4)) and can carry state across calls.

Think of a decorator as gift-wrapping a function. The present inside is unchanged; the wrapper adds a layer that runs before and after. A plain decorator is a fixed wrapping paper. A parameterized decorator is a wrapping service you tell "use the red paper, add a bow" — so it needs one extra step: first you hand over your preferences, then it wraps your present. That extra step is the whole reason the code has one more layer of nesting than beginners expect, and it's exactly where people get lost.

Here is the mistake to inoculate yourself against now, because it costs everyone an hour the first time: a decorator with arguments needs three nested functions, not two — arguments → function → wrapper. Layer 1 exists only because you wrote @retry(...) with parentheses; it swallows the options and hands back the real decorator. Skip it and Python passes your function where you expected times, producing a baffling error. The other near-universal slip is forgetting @functools.wraps(fn): without it the wrapper impersonates the original so completely that the function's __name__ and docstring vanish, breaking logs, tracebacks, and anything that introspects it. Memorize the three-layer shape and always wrap with functools.wraps, and stateful decorators become routine.

P4/P5 introduced decorators; here's the production form — decorators that take arguments and carry state, for cross-cutting concerns like timing, retry, and audit logging that you want to wrap around every tool call. The three-layer nesting (args → function → wrapper) is the pattern to memorize.

pythonimport functools, time

def retry(times=3, exceptions=(Exception,)):   # layer 1: the arguments
    def decorator(fn):                          # layer 2: the function
        @functools.wraps(fn)                     # preserve name/docstring
        def wrapper(*args, **kwargs):            # layer 3: the call
            last = None
            for attempt in range(times):
                try:
                    return fn(*args, **kwargs)
                except exceptions as e:
                    last = e
                    time.sleep(2 ** attempt)        # exponential backoff
            raise last
        return wrapper
    return decorator

@retry(times=4, exceptions=(ConnectionError,))
def call_api():
    ...                                        # retried up to 4x on ConnectionError

6 · Metaclasses — the class of a class expert (use sparingly) intermediate

You'll meet metaclasses first as a stack trace you don't understand. You subclass a framework base — a Pydantic v1 model, a Django model, an ORM table — and something happens the instant the class is defined, before you ever create an object: fields get collected, a subclass gets registered, validation gets wired up. That "how did that run when I only defined the class?" magic is a metaclass at work. The honest goal of this section is not to make you write one — it's to make that stack trace stop being scary, so you can read framework code with your eyes open.

The clean way to think about it: a class is a factory for objects; a metaclass is a factory for classes. Just as Config() runs Config.__init__ to build an instance, writing class Config: ... runs a metaclass to build the class object itself. So a metaclass is "the class of a class" — the thing that gets a chance to inspect and tweak a class at the exact moment it's created. That definition-time hook is genuinely useful (auto-registering plugins, injecting methods, validating that subclasses declare required fields) — which is why frameworks reach for it.

Now the part that saves you from yourself, because this is the classic over-engineering trap: you almost certainly should not write a metaclass. As Tim Peters put it, they're "deeper magic than 99% of users should ever worry about — if you wonder whether you need them, you don't." Nearly every legitimate use has a simpler tool that does the same job with a fraction of the cognitive cost: __init_subclass__ for "do something when a subclass is defined" (the lab below), a class decorator for "transform a class after it's built," or a descriptor for "control one field." Metaclasses also compose badly — combine two libraries that each use one and you can get a metaclass conflict that's miserable to resolve. So the skill this section builds is asymmetric on purpose: recognize metaclasses fluently, write them almost never.

A metaclass customizes class creation — it's to a class what a class is to an instance. Frameworks use them to auto-register subclasses or inject behaviour at definition time. You almost never need one (__init_subclass__ or class decorators usually suffice), but you should recognize the pattern when reading framework code.

python# __init_subclass__ is the lightweight alternative to a metaclass:
class ToolBase:
    registry = {}
    def __init_subclass__(cls, name, **kw):   # runs when a subclass is DEFINED
        super().__init_subclass__(**kw)
        ToolBase.registry[name] = cls          # auto-register by name

class ScaleTool(ToolBase, name="scale"):    # no manual registry.append!
    def run(self): return "scaled"

class RestartTool(ToolBase, name="restart"):
    def run(self): return "restarted"

print(ToolBase.registry)        # {'scale': ScaleTool, 'restart': RestartTool}

7 · A dynamic tool registry advanced

This is where the last six sections stop being party tricks and become an agent. An LLM that "uses tools" is, underneath the hype, doing something almost boringly concrete: the model emits a name and some arguments — {"tool": "get_pods", "namespace": "prod"} — and your code has to find the right Python function for that name and run it. The naïve version is a growing if name == "get_pods": ... elif name == "restart": ... ladder that everyone has to edit every time a tool is added, and that quietly becomes the merge-conflict capital of the codebase. A registry replaces the ladder with a lookup table, and a one-line decorator replaces the manual bookkeeping.

The mental picture is a hotel front desk with a wall of key slots. Each tool, when it's defined, hangs its own key on the wall labelled with its name (@tools.register("get_pods") — the decorator does the hanging). When a request arrives, the desk clerk (dispatch) reads the name, grabs the matching key, and hands it over — one motion, no walking the whole wall. That "grab by name" is a dictionary lookup, which from D3 you know is O(1): it costs the same whether you have five tools or five hundred, and that flat cost is exactly why real frameworks are built this way.

Two design choices in the lab are worth naming because they're the ones that separate a toy from a tool. First, the decorator returns the function unchanged after registering it — so get_pods is still an ordinary function you can call and unit-test directly; registration is a side effect, not a mutation. Second, dispatch guards the lookup and raises a clear KeyError for an unknown name instead of exploding deep inside a bare self._tools[name] — a non-negotiable, because the name is coming from an LLM that will eventually hallucinate a tool that doesn't exist. Skip the guard and that hallucination becomes a cryptic traceback in production; keep it and it becomes a message you can hand straight back to the model.

Tying it together: a real agent needs to register tools by name and dispatch to them — ideally with a one-line decorator per tool. This is the pattern behind every tool-calling framework.

pythonclass Registry:
    def __init__(self):
        self._tools = {}
    def register(self, name):           # decorator factory
        def deco(fn):
            self._tools[name] = fn        # side effect: register at import time
            return fn                      # return fn unchanged
        return deco
    def dispatch(self, name, **kwargs):   # O(1) hash-map lookup (D3)
        if name not in self._tools:
            raise KeyError(f"unknown tool: {name}")
        return self._tools[name](**kwargs)

tools = Registry()

@tools.register("get_pods")
def get_pods(namespace):
    return [f"{namespace}/web-1"]

print(tools.dispatch("get_pods", namespace="prod"))   # ['prod/web-1']

8 · Loading agent plugins at runtime expert advanced

Here's the scenario the whole capstone is built around. Your agent ships to a new company, and their ops team needs a tool you've never heard of — a wrapper around their internal deploy script. If adding that tool means editing your core source, cutting a release, and redeploying, the agent isn't really extensible; it's just a program with a plugin-shaped comment. The goal is the opposite: an operator drops their_deploy.py into a plugins/ folder, restarts the agent, and the new tool is simply there — no fork, no rebuild, no touching your code. That's the difference between software you sell and software people extend themselves.

The trick rests on a fact about Python that's easy to overlook: importing a module runs it, top to bottom. An import isn't a passive "load the definitions" — it executes every top-level statement, decorators included. So if a plugin file contains @tools.register("their_deploy"), the mere act of importing that file runs the registration and the tool appears on §7's front-desk wall, with zero wiring on your side. Think of it like a self-addressed, stamped envelope: the plugin already knows how to file itself; you just have to deliver it to the post office. importlib is that delivery mechanism — it imports a module chosen at runtime by name, rather than baked into a static import at the top of your file — and pkgutil.iter_modules is how you find every envelope in the folder to deliver in the first place.

Say the quiet part out loud, though, because "load whatever's in the folder" is also how you get owned: discovery is not the same as trust. Importing a plugin executes arbitrary code with your process's full privileges — so a real loader discovers explicitly (walk a known plugins package you control) rather than importing anything on the path, and treats the plugins directory as a security boundary, not a free-for-all. The common mistake here isn't technical, it's a category error: auto-registration removes the tedious wiring, it does not remove the need to decide whose code you're willing to run. Get that boundary right and the pattern below — registry plus importlib discovery plus __init_subclass__ — is the complete recipe for an agent that grows new abilities without a redeploy.

For an agent that "onboards into any company" (the capstone), tools shouldn't be hard-coded — they should be discoverable plugins the operator drops into a folder. importlib loads modules by name/path at runtime; combined with the registry, tools register themselves simply by being imported.

pythonimport importlib, pkgutil

def load_plugins(package_name="agent_plugins"):
    package = importlib.import_module(package_name)
    for _, mod_name, _ in pkgutil.iter_modules(package.__path__):
        importlib.import_module(f"{package_name}.{mod_name}")   # import = run @register
    # each imported module's @tools.register(...) has now populated the registry

# importlib also enables hot-reload during development:
#   import importlib; importlib.reload(some_module)

Exercises advanced

🎯 Interview practice interview

The interview questions this topic gets asked — worked, with code. For the full pattern catalog see A9 · Big Tech AI-engineering patterns.

pythonclass Registry:
    def __init__(self): self._tools = {}
    def register(self, name):
        def deco(fn):
            self._tools[name] = fn
            return fn
        return deco
    def call(self, name, **kw):
        return self._tools[name](**kw)

tools = Registry()
@tools.register("scale")
def scale(replicas): return f"scaled to {replicas}"

pythonclass Bounded:
    def __init__(self, lo, hi): self.lo, self.hi = lo, hi
    def __set_name__(self, owner, name): self.attr = "_" + name
    def __get__(self, obj, t=None): return getattr(obj, self.attr)
    def __set__(self, obj, v):
        if not (self.lo <= v <= self.hi):
            raise ValueError(f"{v} out of range")
        setattr(obj, self.attr, v)

Checkpoint advanced

class Adder:
    def __init__(self, base):
        self.base = base
    def __call__(self, x):
        return self.base + x

add10 = Adder(10)
print(add10(5))        # 15
print(callable(add10)) # True

class Config:
    def __init__(self, data):
        object.__setattr__(self, "_data", data)
    def __getattr__(self, name):
        try:
            return self._data[name]
        except KeyError:
            raise AttributeError(name)

cfg = Config({"host": "db.local", "port": 5432})
print(cfg.host, cfg.port)   # db.local 5432
try:
    cfg.missing
except AttributeError as e:
    print("no such key:", e)

class Positive:
    def __set_name__(self, owner, name):
        self.attr = "_" + name
    def __get__(self, obj, owner=None):
        if obj is None:
            return self
        return getattr(obj, self.attr)
    def __set__(self, obj, value):
        if value <= 0:
            raise ValueError("must be positive")
        setattr(obj, self.attr, value)

class Order:
    qty = Positive()
    def __init__(self, qty):
        self.qty = qty

print(Order(3).qty)   # 3
try:
    Order(-1)
except ValueError as e:
    print("rejected:", e)

import functools

def retry(times):
    def deco(fn):
        @functools.wraps(fn)
        def wrapper(*a, **k):
            wrapper.attempts += 1
            last = None
            for _ in range(times):
                wrapper.attempts_this_call = _ + 1
                try:
                    return fn(*a, **k)
                except Exception as e:
                    last = e
            raise last
        wrapper.attempts = 0
        return wrapper
    return deco

calls = {"n": 0}
@retry(3)
def flaky():
    calls["n"] += 1
    if calls["n"] < 3:
        raise RuntimeError("boom")
    return "ok"

print(flaky())            # ok (took 3 tries)
print(flaky.__name__)     # flaky (wraps preserved)

REGISTRY = {}

def tool(fn):
    REGISTRY[fn.__name__] = fn
    return fn

@tool
def add(a, b):
    return a + b

@tool
def greet(name):
    return f"hi {name}"

def call(_name, **kwargs):
    if _name not in REGISTRY:
        raise KeyError(f"unknown tool: {_name}")
    return REGISTRY[_name](**kwargs)

print(sorted(REGISTRY))          # ['add', 'greet']
print(call("add", a=2, b=3))     # 5
print(call("greet", name="Ada")) # hi Ada

REGISTRY = {}

class Tool:
    name = None
    def __init_subclass__(cls, **kw):
        super().__init_subclass__(**kw)
        if cls.name:                       # skip abstract bases
            if cls.name in REGISTRY:
                raise ValueError(f"duplicate tool {cls.name!r}")
            REGISTRY[cls.name] = cls
    def run(self, **kwargs):
        raise NotImplementedError

# --- what a plugin module contains ---
class Search(Tool):
    name = "search"
    def run(self, q):
        return f"results for {q!r}"

class Calc(Tool):
    name = "calc"
    def run(self, expr):
        return eval(expr, {"__builtins__": {}})   # sandboxed builtins

# --- framework dispatch, no manual wiring ---
def invoke(name, **kwargs):
    return REGISTRY[name]().run(**kwargs)

print(sorted(REGISTRY))               # ['calc', 'search']
print(invoke("search", q="gil"))      # results for 'gil'
print(invoke("calc", expr="6*7"))     # 42

Knowledge check check yourself