Hi, PEP 544 specifies this address as "Discussions-To" so I hope I'm at the right address. I think protocols as defined in the PEP are a very interesting idea and I'm thinking of ways of applying them. The first use case is in the context of attrs. attrs has a number of functions that work only on attrs classes; asdict for example (turns an attrs class into a dictionary recursively). We can't really type hint this properly using nominal subtyping since attrs classes don't have an exclusive ancestor. But it sounds like we could use structural subtyping! An attrs class has a special class-level field, __attrs_attrs__, which holds the attribute definitions. So maybe we can define a protocol: class AttrsClass(Protocol): __attrs_attrs__: ClassVar[Tuple[Attribute, ...]] then we could define asdict as (simplified): def asdict(inst: AttrsClass) -> Dict[str, Any]: ... and it should work out. My question is how to actually add this protocol to attrs classes. Now, we currently have an attrs plugin in mypy so maybe some magic in there could make it happen in this particular case. My second use case is a small library I've developed for work, which basically wraps attrs and generates and sticks methods on a class for serialization/deserialization. Consider the following short program, which does not typecheck on the current mypy. class Serializable(Protocol): def __serialize__(self) -> int: ... def make_serializable(cl: Type) -> Type: cl = attr.s(cl) cl.__serialize__ = lambda self: 1 return cl @make_serializable class A: a: int = attr.ib() def serialize(inst: Serializable) -> int: return inst.__serialize__() serialize(A(1)) error: Argument 1 to "serialize" has incompatible type "A"; expected "Serializable" error: Too many arguments for "A" I have no desire to write a mypy plugin for this library. So I guess what is needed is a way to annotate the class decorator, telling mypy it's adding a protocol to a class. It seems to have trouble getting to this conclusion by itself. (The second error implies the attrs plugin doesn't handle wrapping attr.s, which is unfortunate but a different issue.) I have found this pattern of decorating classes and enriching them with additional methods at run-time really powerful, especially when used with run-time parsing of type information (that often gets a bad rep on this list, I've noticed :) The structural typing subsystem seems like a good fit for use cases like this, and I think it'd be a shame if we couldn't make it work somehow.