What does @typing.runtime_checkable change about a typing.Protocol subclass?

### The problem the decorator solves `typing.Protocol` (Python 3.8) describes a *shape*: a class listing the members an object must have, so a static type checker will accept any object that has them, with no inheritance relationship required. That is a compile-time idea. At runtime, `isinstance()` normally answers a *nominal* question — is this object's class somewhere in that class's inheritance tree — and a protocol has no such tree to consult. Rather than silently return a misleading answer, `typing` refuses: `isinstance(obj, P)` against an undecorated protocol raises `TypeError`, with a message stating that instance and class checks can only be used with `@runtime_checkable` protocols. ### What the decorator turns on `@typing.runtime_checkable` marks the protocol class as willing to be tested at runtime. From then on: * `isinstance(obj, P)` is legal, and returns True when the object has an attribute for every member *name* declared on the protocol. * `issubclass(C, P)` is legal too, but only when `P` declares methods and no data members. A protocol carrying an annotated data attribute still supports `isinstance()` while raising `TypeError` on `issubclass()`. The check is deliberately shallow. It compares names — never parameter lists, never return types, never the type of an attribute. A protocol requiring `def fetch(self, since: int) -> list[int]` is satisfied at runtime by any object carrying something called `fetch`, including an integer attribute of that name. ```python from typing import Protocol, runtime_checkable @runtime_checkable class Closable(Protocol): def close(self) -> None: ... class Weird: close = 3 isinstance(Weird(), Closable) # True — the name exists, that is all ``` ### How the lookup is performed Since Python 3.12 the check uses `inspect.getattr_static()` rather than `hasattr()`. `getattr_static` walks the class dictionaries and the instance `__dict__` without invoking the descriptor protocol and without calling `__getattr__`. Two consequences bite in real code. A `property` whose getter raises no longer produces a spurious False — and is never executed by the check, so a check can no longer trigger a side effect. Conversely, an object that fabricates attributes dynamically in `__getattr__` is now *not* accepted, even though `getattr()` on it would succeed; a proxy or lazy wrapper that passed the check on 3.11 can fail it on 3.12 and later. That is the one version-sensitive behaviour to state out loud in an interview. ### What the decorator does not change It does not affect static analysis at all: a type checker already validated structural conformance, including signatures, at every assignment and call site, decorated or not. It does not create an inheritance relationship, and it does not make the protocol instantiable. It only applies to protocol classes — decorating an ordinary class raises `TypeError` immediately, at class-creation time, not at first use. It also does not stop you from subclassing the protocol explicitly; a class that inherits from the protocol satisfies the check trivially and gets its conformance verified by the type checker at the class definition itself. ### Where the runtime check is worth using The honest use is a narrow one: validating an object at an input boundary so a caller gets a clear error immediately, rather than an `AttributeError` three frames deeper, and light branching over optional capabilities ("does this object expose a close method?"). Because the answer is presence-only, treat a True as *probably shaped correctly*, never as a guarantee that the object will behave. Anything stronger — argument counts, types, return values — has to come from the static type checker in CI, or from actually calling the object and handling the failure.