Why does a proxy that forwards attributes via `__getattr__` still raise TypeError on `with proxy:`?

A forwarding proxy is the canonical place this rule draws blood, because the proxy looks like it works. ## The scenario A geocoding batch job builds its client lazily: constructing it costs a 45-second cold start, and most runs of the job never need it. So the client is wrapped in a proxy that builds the real object on first use and forwards everything else: ```python class LazyClient: def __init__(self, factory): self._factory = factory self._real = None def _get(self): if self._real is None: self._real = self._factory() return self._real def __getattr__(self, name): return getattr(self._get(), name) ``` `proxy.geocode(address)` works. `proxy.timeout` works. Then someone writes `with proxy:` to scope the client's session and gets a `TypeError` saying the object does not support the context manager protocol — for an object that demonstrably forwards everything. ## Why the hook is never reached `__getattr__` is the last step of *ordinary* attribute lookup, run by `object.__getattribute__` when nothing else matched. The `with` statement does not perform ordinary attribute lookup. Like every protocol, it uses implicit special method lookup: the interpreter searches the MRO of `type(proxy)` for `__enter__` and `__exit__`, applies the descriptor protocol, and calls what it finds. The instance dictionary is skipped and so are `__getattribute__` and `__getattr__` — at every level, including on a metaclass. There is no interception point. `len(proxy)`, `iter(proxy)`, `proxy[0]`, `proxy + 1` and `-proxy` all fail the same way. And overriding `__getattribute__` instead does not help, for exactly the same reason: implicit lookup does not call it either. ## The dangerous half: the ones that do not fail If every protocol raised, the bug would be found in five minutes. It does not, because `object` sits at the root of every MRO and already defines several dunders. `str(proxy)` and `repr(proxy)` find `object.__str__`/`object.__repr__` and print `<__main__.LazyClient object at 0x...>` instead of the wrapped object's representation — so logs quietly describe the wrapper. `proxy == other` finds `object.__eq__` and compares identity. `hash(proxy)` hashes the wrapper. And `object` defines no `__bool__`, while the proxy has no `__len__`, so `bool(proxy)` is unconditionally `True`: a truthiness check on a wrapped empty collection silently takes the wrong branch. The geocoding batch fails in the sharpest version of this. Someone hand-writes `__exit__` on the proxy to make `with` work and returns the wrapped object's method by mistake instead of calling it: ```python def __exit__(self, *exc_info): return self._get().__exit__ # BUG: a bound method, not its result ``` A bound method is truthy, and a truthy `__exit__` return *suppresses the exception*. Every failure inside the `with` block — a bad address, a timeout, a quota error — is swallowed; the batch exits zero and reports success while whole regions are unresolved. The rule that made the proxy incomplete then made the incomplete fix silent. ## Doing it properly Declare each special method on the proxy *class*, and generate them rather than writing thirty by hand: ```python FORWARDED = ("__len__", "__iter__", "__contains__", "__str__", "__enter__", "__exit__") def _forward(name): def method(self, *args): return getattr(self._get(), name)(*args) method.__name__ = name return method for _name in FORWARDED: setattr(LazyClient, _name, _forward(_name)) ``` Points of craft. Choose the list explicitly — a proxy that forwards `__class__` will lie to `isinstance`, and one that forwards `__hash__` while forwarding `__eq__` inconsistently corrupts dictionaries. Forward the protocols you actually promise. Return the *result* of the wrapped call, never the callable. Remember that a dunder is looked up on the type, so this generation must run at class creation (a loop after the `class` statement, a decorator, `__init_subclass__` or a metaclass), never inside `__init__`. In the standard library, `weakref.proxy` implements this forwarding in C over a broad set of slots, which is a useful existence proof but is tied to weak references and not a general wrapper. Finally, test the protocols explicitly. A proxy's test suite that only calls methods will pass forever while `bool()`, `len()`, `in`, `str()` and `with` are all quietly wrong. ## The interview shape of this The question is usually posed as a puzzle — "this proxy forwards everything, why does `with` fail?" — and what is being assessed is whether you reach for the object model instead of guessing at the wrapped object. A complete answer names the two lookup paths, says that `__getattribute__` is no better an interception point than `__getattr__`, distinguishes the protocols that raise from the ones `object` quietly satisfies, and ends on the design question of how transparent a wrapper should try to be. Transparency is a spectrum: a proxy that forwards a handful of named protocols is honest and debuggable, while one that also forwards `__class__` to fool `isinstance` is a wrapper that lies to every tool that inspects it, including your own logging and your test doubles. Where a proxy exists purely to defer construction, the smaller answer is often better — hand callers an explicit accessor and keep the wrapper out of the protocol business entirely.