私は過去に abc を使用していましたが、@abstractmethod を使用して純粋な仮想のようなメソッドを強制するために、それらを再度使用したいと思います。これは、ユーザーが頻繁に拡張する API への Python フロントエンドのコンテキストにあります。
スケールの信頼できる包括的なテストを開発するのは少し複雑すぎます.abcを常に黒魔術のクローズドボックスとして使用してきたため、抽象化と抽象化のチェックのコストがどこにあるのか、いつ発生する可能性が高いか、実際のコストがどのようなものになるか、何に合わせてスケーリングするか。
根底にある力学の十分に完全な情報をどこにも見つけることができなかったので、魔法がいつどこで発生し、どのようなコストで発生するかについての指針は非常に高く評価されます (インポート? インスタンス化? インスタンスが拡張された場合の二重浸漬コスト?)
ユース ケースに関する追加情報: 以前のユース ケース (私にとって) とは異なり、各ベース オブジェクトと abc のインスタンスの数が非常に限られており、オーバーヘッドが認識できないほど測定されていましたが、今回は何か (ノード内のノードツリー ビューを備えた DAG) は、インスタンス化してその場で何百回も拡張できます。また、仮想メソッドの数は、クラスごとに約 12 個まで増加する可能性があります。
継承は決して複数ではなく、一般的に非常に浅く、多くても 2 つまたは 3 つ深く、ほとんどの場合は 1 つだけです。
サードパーティのプラットフォームの制約により、Python 2.7。