How do you declare method and attribute members inside a typing.Protocol body?

## The two kinds of member A protocol body declares what a conforming value must offer. There are two shapes of declaration and they behave differently, which is where most of the interview value in this topic sits. **Method members** are written as a normal `def` with `...` as the body: ```python from typing import Protocol class Converter(Protocol): def convert(self, doc: str) -> bytes: ... ``` The body is never called during checking and is irrelevant to conformance -- the signature is the contract. The checker compares parameter kinds (positional-only, keyword-only, `*args`, `**kwargs`), parameter names for anything callable by keyword, defaults, and the return type. An implementation may widen a parameter type and narrow a return type; it may not rename a keyword parameter, because callers of the protocol are free to pass it by name. **Data members** are bare annotations: ```python class Job(Protocol): doc_id: str retries: int ``` This is a stronger claim than it looks. A bare annotation declares a mutable instance attribute, so consumers of `Job` are entitled to *write* `job.doc_id = "..."`. As a result an implementation that exposes `doc_id` through a read-only `property` does **not** conform, and the checker says so. This surprises people who think of the annotation as "must have an attribute called `doc_id`". It also means data members are invariant: the implementation's type must match exactly, not merely be a subtype, because both reading and writing are allowed. ## Declaring read-only and class-level members To declare a member that consumers may only read, declare it as a property in the protocol: ```python class Job(Protocol): doc_id: str # read-write @property def attempts(self) -> int: ... # read-only ``` Now an implementation may satisfy `attempts` with a property, a cached computation, or a plain instance attribute -- a plain attribute is readable, so it is compatible with a read-only requirement, while the reverse is not true. This asymmetry is the practical rule: **declare the weakest thing you need**, because a read-only declaration accepts strictly more implementations than a read-write one. For something that lives on the class rather than the instance, annotate with `typing.ClassVar`: ```python from typing import ClassVar, Protocol class Converter(Protocol): fmt: ClassVar[str] def convert(self, doc: str) -> bytes: ... ``` A `ClassVar` member is satisfied by a class-level attribute and may not be assigned per instance. ## Bodies, defaults and abstractness A protocol member does not have to be `...`. Give it a real body and it becomes a **default implementation**: classes that list the protocol as an explicit base class inherit it, while classes that merely match structurally do not get it -- they were never related to the protocol at runtime. This makes a protocol with one or two convenience methods a reasonable mixin for implementations that opt in, without closing the door on implementations that do not. Two runtime facts matter here. First, protocol members written as `...` are **not** abstract: unless the member is also decorated with `abc.abstractmethod`, a concrete subclass that forgets to implement it still instantiates, and calling that member returns `None`. Only a static checker catches the omission. Second, the annotations in the body create no attributes at all. `doc_id: str` adds an entry to the class's annotations and nothing else; implementations must actually assign the attribute, normally in `__init__`. A protocol is never a source of state. ## Annotations on 3.14 Since Python 3.14 (PEP 649/749) annotations are evaluated lazily rather than at class-creation time, and this applies inside protocol bodies like anywhere else. A member may reference a class defined later in the file without quoting it, and the annotation resolves when something asks for it -- `typing.get_type_hints`, or `annotationlib.get_annotations` for finer control over whether you want the evaluated object, a string, or a forward-reference form. On earlier versions the same code needed a string literal or a `from __future__ import annotations` at the top of the module. ## Keeping protocols small Because every declared member is a demand on every implementation, protocol size is a design decision, not a documentation exercise. List what the consumer actually touches. A protocol with eight members, six of which one call site uses, is the structural-typing equivalent of a fat interface -- it rejects perfectly usable objects for no benefit and pushes implementers toward writing stubs that exist only to satisfy the checker.