__copy__ and __deepcopy__

## The copy module asks the object first `copy.copy()` and `copy.deepcopy()` are not magic reflection over `__dict__`. They are dispatchers, and the first substantive thing each one does after handling a handful of built-in types is ask the object how it wants to be copied. The two hooks are the answer to that question. **`__copy__(self)`** is called by `copy.copy()`. It takes no arguments beyond `self` and returns the shallow copy. **`__deepcopy__(self, memo)`** is called by `copy.deepcopy()`. It receives the *memo* dict belonging to the current deep-copy pass and returns the deep copy. In both cases the return value is final. The module does not inspect it, fix it up, or copy anything further; the hook is responsible for producing a complete, usable object. ## The lookup order in CPython 3.14 For `copy.copy(x)`, with `cls = type(x)`: 1. atomic types (`int`, `str`, `tuple`, `frozenset`, functions, `type`…) are returned unchanged; 2. the built-in containers `list`, `dict`, `set` and `bytearray` are copied with their own `copy` method; 3. classes themselves are returned unchanged; 4. **`cls.__copy__`**, if present, is called; 5. `copyreg.dispatch_table` is consulted for a registered reductor; 6. finally `x.__reduce_ex__(4)` is called and the object is rebuilt from what comes back. `copy.deepcopy(x, memo)` follows the same shape: atomic types short-circuit, an internal per-type dispatch table handles lists, dicts, tuples and sets, then **`__deepcopy__`**, then `copyreg.dispatch_table`, then `__reduce_ex__(4)`. Two details are worth carrying into an interview. First, `copy.copy()` looks `__copy__` up on the *type*, so the usual special-method rule applies and an instance attribute of that name is ignored; CPython's `deepcopy`, by contrast, looks `__deepcopy__` up on the *instance*, so an instance attribute there does take effect. Second, defining `__copy__` does nothing for `copy.deepcopy()` and vice versa — they are separate hooks, and a class that needs both must define both. ## Writing the hooks The idiomatic body allocates without running `__init__`, because `__init__` typically demands constructor arguments you no longer have and may open resources you are trying to share rather than recreate: ```python def __copy__(self): cls = type(self) new = cls.__new__(cls) new.__dict__.update(self.__dict__) return new ``` Note `type(self)`, not the class name spelled out. A hook that hardcodes `Stage.__new__(Stage)` silently downgrades every subclass copy to a `Stage`, and that bug survives tests that only ever copy the base class. A `__deepcopy__` differs in three ways: it must register the new object in `memo` before recursing, it must pass `memo` down to every nested `copy.deepcopy(child, memo)` call, and it is where you decide, attribute by attribute, what gets duplicated and what gets shared. ## The pickle-protocol fallback When a class defines neither hook, copying still works for the vast majority of ordinary objects. The module falls through to the same description of the object that pickling uses — a reductor from `copyreg.dispatch_table` if one is registered, otherwise `__reduce_ex__(4)`, which by default reports the class and the instance state — and rebuilds a new object from it. Nothing is serialized: no bytes are produced, no file or socket is involved, and the pieces are reused in memory. Two consequences follow. A class that already customizes its pickled form generally gets matching copy behaviour for free, which is the usual reason not to write these hooks at all. And a class holding something that cannot be reduced — a `threading.Lock`, an open socket — raises `TypeError` from a deep copy even though nobody asked for pickling, because the fallback is the pickle machinery. ## When to define them Define `__copy__` or `__deepcopy__` when copying genuinely differs from pickling: an attribute must be shared rather than duplicated, a cache must be dropped and rebuilt lazily, or the default recursion is prohibitively expensive for a large graph. Otherwise leave them out. Every hand-written hook is a second constructor that must be kept in step with the real one, and the most common bug in this area is a hook that quietly stops copying an attribute added to `__init__` a year later. ## What copying never touches, and what it refuses Some types are deliberately outside the whole mechanism. Modules, classes, functions, methods, tracebacks and frames are treated as atomic: `copy.copy()` and `copy.deepcopy()` return the very same object, because duplicating them would be meaningless rather than helpful. That is why a deep copy of a container full of function references stays cheap, and why the functions in the copy are still the functions you registered. At the other end, when no hook, no registered reductor and no usable `__reduce_ex__` can be found, the module raises `copy.Error` — the module's own exception class. In practice you are far more likely to see a `TypeError` escaping from the reduce fallback, complaining that some attribute cannot be pickled, which is the same fallback path reporting the failure one level down. Knowing which of the two you are looking at tells you immediately whether the problem is the object itself or something it holds.