From the PEP:
> The problem with them is that a class has to be explicitly marked to support them, which is unpythonic and unlike what one would normally do in idiomatic dynamically typed Python code.
> The same problem appears with user-defined ABCs: they must be explicitly subclassed or registered.
Neither of these statements are entirely true. The semantics of `abc` allow for exactly the kind of detached interfaces this PEP is attempting to provide. The `abc.ABCMeta` provides the `__subclasshook__` which allows a developer to override the default check of internal `abc` registry state with virtually any logic that determines the relationship of a class with the interface. The prior art I linked to earlier in the thread uses this feature to generically support `issubclass` and `isinstance` in such a way that the PEPs goal is achieved.
> The intention of this PEP is to solve all these problems by allowing users to write the above code without explicit base classes in the class definition
As I understand this goal, you want to take what some of us in the community have been building ourselves and make it canonical via the stdlib. What strikes me as odd is that the focus is on 3rd party type checkers first rather than introducing this as a feature of the language runtime and then updating the type checker contract to make use of it. I see a mention of the `isinstance` check support in the postponed/rejected ideas, but the only rationale given for it being in that category is, generally, "there are edge cases". For example, the PEP lists this as an edge case:
>The problem with this is instance checks could be unreliable, except for situations where there is a common signature convention such as Iterable
However, the sample given demonstrates precisely the expected behavior of checking if a concrete implements the protocol. It's unclear why this sample is given as a negative. The other case given is:
> Another potentially problematic case is assignment of attributes after instantiation
Can you elaborate on how type checkers would not encounter this same issue? If there is a solution to this problem for type checkers, would that same solution not work at runtime? Also, it seems odd to use a custom initialize function rather than `__init__`. I don't think it was intentional, but this makes it seem like a bit of a strawman that doesn't represent typical Python code.
> Also, extensive use of ABCs might impose additional runtime costs.
I'd love to see some data around this. Given that it's a rationale for the PEP I'd expect to see some numbers behind it. For example, is memory cost of directly registering implementations to abc linear or worse? What is the runtime growth pattern of isinstance or issubclass when used with heavily registered or deeply registered abc graphs and is it different than those calls on concrete class hierarchies? Does the cost affect anything more than the initial evaluation of the code or, in the absence of isinstance/issubclass checks, does it continue to have an impact on the runtime?