Nick Coghlan added the comment:
> Antoine Pitrou added the comment:
>> To be clear: the problem is with CPython calling the concrete APIs when
>> it shouldn't, rather than with the concrete APIs not behaving properly.
> 
> The boilerplate required to use them correctly renders them broken in my
> view

I think we disagree here. There is no boilerplate at all involved, as long
as its guaranteed that they are being called on the correct type of object.
User code may provide that guarantee either implicitly or explicitly, and
only the explicit way involves additional code (such as a type check). The
implicit way (that simply knows the exact type) would suffer from any code
additions to the fast paths in the specific C-API functions.

> particularly when they silently corrupt internal subclass state when
> misused instead of throwing an exception.

It has bothered me more than once that even the fast paths in those
functions usually contain type checks, which often means that the type
check is being executed twice: once as a special casing check before
calling the function and once as a safety check after entering it. As long
as the functions are being used correctly, the second check is just useless
code that unnecessarily takes time.

IMHO, it would be nice to have those internal type checks enabled *only*
for debug builds, although even then, there may be legitimate usages that
call these functions on subtypes (such as when called from within a well
defined subtype implementation, as you mentioned).