Why does issubclass() raise TypeError for a runtime_checkable Protocol with a data attribute?

### Two checks, two amounts of information `@typing.runtime_checkable` unlocks both `isinstance()` and `issubclass()`, but they are not equally answerable. `isinstance(obj, P)` has an object in hand. Resolving a member name can consult the type, its bases, and the instance's own `__dict__`. So a protocol declaring `cursor: int` can be tested: the object either has a `cursor` or it does not. `issubclass(C, P)` has only a class. For a method member that is fine — methods are defined in the class body, so `C` either carries the name or it does not. For a data member it is usually hopeless. The overwhelmingly common Python idiom assigns instance state in `__init__`: ```python class Sync: def __init__(self) -> None: self.cursor = 0 ``` Nothing named `cursor` exists on `Sync` itself. A class-level check would have to answer False for a class whose every instance satisfies the protocol perfectly — a false negative baked into the language. The alternative, answering True whenever an annotation exists, would be a false positive, since a bare annotation in a class body creates no attribute at all. ### What Python does instead It refuses. `issubclass(Sync, HasCursor)` raises `TypeError`, with a message stating that protocols with non-method members do not support `issubclass()` and naming which members are the problem. That naming matters in practice: on a protocol with a dozen members the message points straight at the one annotation that closed the door. The rule is a property of the protocol, not of the argument. A protocol whose members are all methods supports `issubclass()`. Adding a single annotated attribute disables it permanently for that protocol, while leaving `isinstance()` fully functional. ### The workarounds * **Use `isinstance()`.** Almost always the right answer, because almost always you have an object. This is the intended path for data protocols. * **Express the requirement as a method.** A protocol that declares `def cursor(self) -> int: ...` is method-only, so both checks work, at the cost of a call at the use site. A `property` declared in the protocol body is still a non-method member for this purpose, so it does not buy back `issubclass()`. * **Declare class-level state.** If the attribute genuinely lives on the class — a class constant, or a value set by a metaclass — you can check for it with `inspect.getattr_static()` on the class yourself. But you are then writing the check by hand, not asking the protocol machinery. * **Subclass explicitly.** An implementation inheriting from the protocol satisfies `issubclass()` nominally and gets validated by the type checker at its own definition, sidestepping the whole question. ### The related version detail Python 3.12 tightened the surrounding machinery in two ways worth knowing. The lookup performed by `isinstance()` moved from `hasattr()` to `inspect.getattr_static()`, so a data member provided only through `__getattr__` no longer satisfies the check while one sitting in the instance `__dict__` still does. And the member list of a runtime-checkable protocol is settled when the class is created: monkey-patching attributes onto the protocol afterwards still works as an ordinary attribute assignment but has no effect on later `isinstance()` results. Both behaviours stand on 3.14. ### How to say it in an interview Lead with the information asymmetry rather than the error message: `issubclass()` is handed a class and asked a question whose answer lives on instances, so the language raises instead of guessing. Then note that this is exactly why a protocol intended for class-level checks — a plugin registry validating classes before instantiating them, say — should be written with methods only.