Advanced & Dynamic Python Mechanics

When you write c.name in Python, that dot is not a simple memory read — Python runs a small search to find where name lives. This lab shows the search order and where two different kinds of attribute actually get stored.

1. The comment block at the top lists the real lookup order Python follows for obj.x. The one to remember: it checks the instance's own storage before falling back to the class. If nothing is found anywhere, you get an AttributeError.
2. Inside Config, debug is set at the class level, so it is a class attribute — one copy shared by every Config object. self.name is set inside __init__, so it is an instance attribute — a private copy living on that one object.
3. Every object keeps its own instance attributes in a hidden dictionary called __dict__. So c.name is found in c.__dict__, but c.debug is not there — Python doesn't give up, it looks at the class next and finds it.
4. type(c).__mro__ prints the Method Resolution Order: the exact chain of classes Python walks when the instance itself doesn't have the attribute. Here it is (Config, object).

What the output means: Three lines: agent (from the instance), False (found on the class), and (<class 'Config'>, <class 'object'>) — the search path itself.

Try this: Add c.debug = True after creating c, then print c.debug and Config.debug. You'll see the instance now has its own debug that shadows the shared class one — proof that the instance is checked first.

__getattr__ is a hook Python calls only when normal attribute lookup fails — i.e. the name was not found on the instance or its class. That single fact lets you fake attributes that don't really exist, which is how dotted-config objects and lazy clients work.

1. DotConfig stores a plain dictionary in self._data. When you ask for cfg.model and there is no real model attribute, Python calls __getattr__(self, "model"), which looks the key up in _data and returns it.
2. If the key is missing it raises AttributeError — the correct error for "no such attribute". The from None just hides the internal KeyError so the message stays clean.
3. The clever line is return DotConfig(v) if isinstance(v, dict) else v: if a value is itself a dict, it gets wrapped in another DotConfig. That is why cfg.limits.rpm chains with dots all the way down.
4. LazyClient uses the same hook to defer expensive work. The real client is None until the first attribute access; on that first call it prints, builds the real object, and from then on just forwards to it.

What the output means: cfg.model gives 'claude-opus-4-8' and cfg.limits.rpm gives 50 — even though neither attribute was ever explicitly defined on the class.

Try this: Ask for cfg.missing. Because the key isn't in _data, __getattr__ raises AttributeError — exactly what a real missing attribute would do.

Normally only functions can be "called" with parentheses. Defining a __call__ method makes an instance itself callable — you can write scale(...) even though scale is an object, not a function. The payoff is that the object can remember things between calls.

1. Tool.__init__ stores a name, a function fn, and a counter calls that starts at 0 — ordinary per-instance state.
2. __call__(self, **kwargs) is the special method that runs when you put parentheses after the object. It bumps self.calls by one, then hands the arguments to the stored fn and returns its result.
3. scale = Tool("scale", lambda replicas: ...) builds one such object; the lambda is just a tiny inline function used as the tool's body.
4. scale(replicas=3) looks like a function call but actually triggers __call__. Afterwards scale.calls is 1 — the count survived because it lives on the object.

What the output means: First line prints scaled to 3; second prints 1, the number of times the tool has been called.

Try this: Call scale(replicas=5) a second time, then print scale.calls — it reads 2. A plain function couldn't keep that running count without a global variable.

A descriptor is an object that controls what happens when you read or write a particular attribute. Put one as a class attribute and its __get__/__set__ methods run every time that field is accessed — this is the exact machinery behind @property, ORM columns, and Pydantic fields.

1. Bounded holds a low and high limit. __set_name__(self, owner, name) is called automatically when the class is defined; Python tells the descriptor the attribute name it was assigned to, and it saves a private storage key like _temperature.
2. __get__ runs on reads. It fetches the real value from the private slot with getattr(obj, self.attr). (The if obj is None guard handles access on the class itself rather than an instance.)
3. __set__ runs on writes and is where validation happens: if the value is outside [lo, hi] it raises ValueError; otherwise it stores it with setattr(obj, self.attr, value).
4. In GenConfig, temperature = Bounded(0.0, 1.0) attaches a descriptor to the field. So the ordinary-looking line self.temperature = temperature in __init__ secretly runs __set__ and gets validated.

What the output means: GenConfig(0.7, 0.9) succeeds silently. The commented-out GenConfig(2.0, 0.9) would raise ValueError: 2.0 not in [0.0, 1.0] because 2.0 fails the range check in __set__.

Try this: Uncomment (or type) GenConfig(2.0, 0.9) and run it. The error proves the descriptor guards the field on every assignment, not just at construction.

A decorator wraps a function to add behaviour around it. A parameterized decorator — one you call with arguments like @retry(times=4) — needs three nested layers. Getting why there are three is the whole lesson here.

1. Layer 1 retry(times=3, exceptions=...) takes the decorator's arguments and returns the actual decorator. This layer exists only because we wrote @retry(...) with parentheses.
2. Layer 2 decorator(fn) receives the function being decorated (here call_api) and returns its replacement.
3. Layer 3 wrapper(*args, **kwargs) is what actually runs when you call the function. It loops up to times, returns on success, and on a matching exception sleeps with time.sleep(2 ** attempt) (waits 1s, then 2s, then 4s…) before retrying.
4. @functools.wraps(fn) copies the original function's name and docstring onto the wrapper so it doesn't lose its identity. If every retry fails, raise last re-raises the final error.

What the output means: Nothing prints on its own — this defines the tool. Applied to call_api, it means call_api() will be attempted up to 4 times, retrying only on ConnectionError.

Try this: Change times=4 to times=1: now there is no retry at all — the first failure propagates immediately. The argument you pass in Layer 1 controls Layer 3's loop.

Frameworks often want every subclass to register itself automatically the moment it is defined — no manual list to keep in sync. The heavy tool for this is a metaclass, but __init_subclass__ is the modern, far simpler way to do the same thing.

1. ToolBase keeps a shared dictionary registry = {} at the class level.
2. __init_subclass__(cls, name, **kw) is a special hook that runs once, when a subclass is defined (not when instances are created). cls is the new subclass being created.
3. Each time a subclass appears, the hook does ToolBase.registry[name] = cls — storing the class under the name passed in the class header. That's the automatic registration.
4. class ScaleTool(ToolBase, name="scale") passes name="scale" right in the class definition line; that value arrives as the name argument of __init_subclass__. No .append() call anywhere.

What the output means: {'scale': ScaleTool, 'restart': RestartTool} — both tools registered themselves simply by being defined.

Try this: Add class DrainTool(ToolBase, name="drain"): ... and print the registry again. It now includes 'drain' — you never touched the registry code, the class wired itself in.

This is the pattern behind real tool-calling agents: register functions by name with a one-line decorator, then look one up and call it by that name. It combines the decorator idea (§5) with a plain dictionary for fast lookup.

1. Registry.__init__ creates an empty dict self._tools that will map name → function.
2. register(self, name) is a decorator factory: you call it with a name, and it returns the real decorator deco. Inside deco, the function is stored under that name and then returned unchanged — so the original function still works normally.
3. dispatch(self, name, **kwargs) is the lookup: it checks the name exists (raising KeyError if not), then calls the stored function with whatever keyword arguments you pass. Dictionary lookup is O(1) — instant regardless of how many tools you have.
4. @tools.register("get_pods") above def get_pods(...) runs at import time and quietly adds the function to the registry, so it is ready to dispatch later.

What the output means: ['prod/web-1'] — dispatch found get_pods by name and called it with namespace="prod".

Try this: Call tools.dispatch("nope"). You get KeyError: unknown tool: nope — the guard clause in dispatch turning a missing name into a clear error.

The final piece: instead of hard-coding tools, let an operator drop new tool files into a folder and have the agent discover them at runtime. importlib imports modules by name, and importing a module runs its top-level code — including its @register decorators.

1. importlib.import_module(package_name) imports the plugins package (a folder of Python files) so we can inspect it.
2. pkgutil.iter_modules(package.__path__) walks that folder and yields the name of every module inside it — this is the "discovery" step.
3. For each one, importlib.import_module(f"{package_name}.{mod_name}") imports it. That act of importing runs the module's code, so any @tools.register(...) lines inside execute and populate the registry — no manual wiring.
4. The trailing comment notes importlib.reload(...), which re-imports a module you've edited — handy for hot-reloading plugins while developing.

What the output means: No visible output by itself. The effect is a side effect: after load_plugins() runs, the registry from §7 contains every tool defined in the plugins folder.

Try this: Combine §7 and §8 in your head: an operator adds my_tool.py containing @tools.register("my_tool"), and simply importing it makes the agent able to call it — no core code changes.

This is the interview-sized version of the registry from §7 — the same idea trimmed to what you'd write on a whiteboard. Interviewers ask it to see whether you understand decorators and dictionary dispatch.

1. Registry holds one dict, self._tools, mapping a name to a function.
2. register(name) returns the inner decorator deco, which stores the function under name and returns it unchanged — the decorator-factory pattern in its shortest form.
3. call(name, **kw) simply looks the function up by name and calls it with the given keyword arguments.
4. @tools.register("scale") above def scale(replicas) registers the function the instant the file is imported.

Try this: Be ready to explain why register returns a function that returns a function: the outer call captures the name, the inner deco captures the decorated function. That two-step is exactly what @decorator(arg) needs.

The interview-sized descriptor — the compact cousin of Bounded from §4. Being able to write this from memory signals you understand what @property and ORM/Pydantic fields do underneath.

1. __set_name__ captures the attribute's name and derives a private storage key (_name) so the value has somewhere real to live.
2. __get__ returns that stored value on reads; __set__ validates the range on writes and raises ValueError if it's outside [lo, hi].
3. The key insight to state out loud: the descriptor is a class attribute, but it stores each instance's value on the instance (via the _name slot), so two objects don't clash.

Try this: Explain when you'd reach for a descriptor over a plain @property: a descriptor is reusable across many fields and classes, whereas a @property is written once per attribute.