我过去曾使用过abc，并且我想再次使用它，用@abstractmethod强制执行纯虚拟方法。这是用户将经常扩展的API前端的上下文。
对我来说，开发一个可靠的全面尺度测试对我来说有点太复杂了，而且我总是使用abc作为黑魔法封闭盒子，所以我不知道成本在哪里摘要的抽象和检查是，当它可能发生时，或者实际成本是什么或者它的规模是什么。
我无法在任何地方找到令人满意的基础机制的完整信息，所以任何关于魔法发生的时间和地点以及成本的指示都会得到极大的重视（导入？实例化？如果实例扩展，则需要双倍的成本） ？）
有关用例的更多信息： 与以前的用例（对我来说）不同，每个基础对象的实例数量非常有限，并且abc被测量为没有可感知的开销，这次是针对某些事情（具有树视图的DAG中的节点）可以实例化然后扩展数百次，虚拟方法的数量可能会达到每个类别大约十几个。
继承绝不是多重的，而且它通常很浅，最多两三个深，大部分时间只有一个。
Python 2.7由于第三方平台的限制。
答案 0 :(得分：1)
在Python 2.6之前，使用ABC带来了一些重要的开销。 Issue 1762报告这是一个错误，并且已经修复了Python 2.6（通过将一些ABC机制移动到object的C实现中）。
在较新版本的Python中，ABC使用和非ABC使用类之间的性能差异应该很小（该bug提到了isinstance检查速度的非常小的差异，但其他行为性能差异基本为零）。