In this section I will attempt to compare and contrast ABCs to other approaches that have been proposed.
ABCの導入はDuck Typingの終わりを意味するのか？私はそうは思わない。Pythonは __getitem__ メソッドが定義されている時にクラスが BasicMapping や Sequence に由来することを求めないし、x がABCのインスタンスであることを x[y] 構文が求めることもない。書き込みメソッドを持つ限り"file-like"なオブジェクトを sys.stdout に結びつけることが未だ可能である。
もちろん、適切な基底クラスから派生させるために使用者を励ます餌は存在する;これらは、特定の機能のデフォルトの実装からmappingとsequenceを区別するための改良された機能に変わる。しかしそこにスティックは存在しない。もし hasattr(x, "__len__") が動けば素晴らしい！ABCはmappingとsequenceの区別といったPython2に良い解決法が存在しない問題を解決するためのものである。
ABCは総称型関数(GF)と互換性がある。例えば、私の総称型関数の実装[4](訳注: リンク切れ)ではディスパッチキーとして引数のクラスを使用し、派生クラスが基底クラスをオーバーライドできるようにしている。ABCは(Pythonの観点から)かなり普通のクラスなので、GFのためにデフォルト実装でABCを使うのは適切である。例えば、オーバーロードされた prettyprint 関数があるとき、次のように集合の pretty-printing を定義するのにそれは完全に筋が通る。
@prettyprint.register(Set)
def pp_set(s):
return "{" + ... + "}" # Details left as an exerciseSet の特定のサブクラスの実装を簡単に追加することができる。
ABCは、PEAKにおけるPhillip EbyによるGF実装である RuleDispatch に対して何も問題を提起しないと私は考える。
もちろん、GF支持者はGF(及び具体的な、あるいは実装クラス)が全て必要であると主張するかもしれない。しかし彼らが継承の有用性を否定することはない; オプションの実装基底クラスとしてPEPで提案されているABCを容易に考えることができる。全てのユーザ定義mappingが BasicMapping から派生する必要性はない。
ABCは本質的にinterfaceと互換性がないが、かなり重複している。今の所は、なぜinterfaceが良いのかはinterfaceの支持者に任せる。"mapping-ness"の様々な色合いや命名方の定義に通じた作業の多くが、ABCの代わりにinterfaceを使うという提案に容易に適合されることを私は期待する。
この文脈におけるinterfaceは、通常のクラスヒエラルキーの一部ではないクラスに付加される追加のメタデータ要素の提案の集合を指すが、特定の型の継承テストが可能である。
そのようなメタデータは、少なくともいくつかの提案では、アプリケーションによって容易に変更可能であり、アプリケーションの実装者がオブジェクトの通常の分類をオーバーライドできるように設計される。
クラスに変更可能なメタデータを付加するというアイデアの欠点は、クラスが共有状態にあることで、これを変更することは糸に矛盾の生じるおそれがある。さらに、オブジェクトの分類をオーバーライドする必要性は総称型関数を用いることでより明確に行うことができる:最も簡単なケースでは、基底実装で単に False を返す"category membership"総称型関数を定義し、関心のある全クラスに対して True を返すようなオーバーライドを提供することができる。