Where would you use `typing.Protocol` where you wouldn't use an abstract base class (or a bunch of them as mixins)? My understanding is that the latter is more "formal", whereas `Protocol` is better suited for gradual typing (i.e., moving a more "free-form" codebase into something MyPy won't complain about).

The only time I've ever used `Protocol` is to define a type that makes it explicit that I need an object to have a `__str__` implementation:

    @runtime_checkable
    class Stringable(Protocol):
        """ Protocol type that supports the __str__ method """
    
        @abstractmethod
        def __str__(self) -> str:
            """ Return the string representation of an object """

I've since learned that this is redundant, because all Python objects have an implicit `__str__` if one isn't specified (IIRC). When I didn't know this (when I implemented the above), I didn't use an ABC because obviously I can't guarantee all objects (e.g., those outside of my control) are subclasses of said ABC. The cases where this is true are vanishingly small, especially when you go big on dependency inversion.