哪个 SKLearn 接口定义了 .fit、.predict 等

Question

sklearn.base更具体地说BaseEstimator，检查和不同的混入，很明显，一些混入依赖于调用.fit或的能力.predict。

例如，如果我们查看 ，RegressorMixin我们会看到它依赖于.predict方法。

我的问题是为什么没有强制实现这些方法的接口/抽象类的实现？

我希望有一些像BaseRegressor有.predict()作为一个抽象的方法，并BaseClassifier有.predict_proba()和.predict()-或类似的东西

Answer 1

有几件事一起可以让我们更清楚为什么事情是在像这样的包中完成的scikit-learn：

• 鸭子类型与继承：您可以找到很长的关于哪种方法更好的争论，虽然它们都有各自的优点和缺点，但归根结底，这取决于社区中的人们的习惯。作为一个现在经常使用 Python 的人，我喜欢鸭子类型，而且我对此感到非常舒服。与此同时，15 年前，我喜欢抽象类和 OOP 之类的东西，我不明白为什么你会以其他方式做事。我想说的是，Python 中的人们喜欢鸭子类型，这就是为什么你经常在它的一些核心包中看到这种模式的部分原因。

• 鸭子类型、contrib 包和扩展：有时检查输入，我们可以检查其类型，或者鸭子类型以实现特定功能。如果我们检查类型，这意味着该方法的任何输入实际上都应该从这些类继承，而如果您鸭子类型，它们可以简单地实现这些方法，并且它们很好。这很重要，因为如果开发人员在外部编写估计器scikit-learn，例如，他们希望与 的某些部分兼容scikit-learn，则他们不必scikit-learn作为依赖项进行依赖（因为这样他们就可以从 继承某个类）包），并简单地实现这些方法。如果开发人员有保持其包及其依赖项轻量级的约束，那么这就变得相关（并且我们已经在 中看到了这些确切的问题scikit-learn）。

• Mixin类：类背后的想法Mixin并不是子类应该继承它们并实现它们的方法；但更多的是通过它们向现有类添加功能，而无需复制/粘贴或重新实现任何方法。例如，将方法TransformerMixin添加fit_transform到对象中，假设它已经具有fit和transform，而不关心对象是估计器还是转换器。同样，您可能会争论 OOP 中的某种设计模式在这里可能更好，但这是一个永无休止的争论，而且这种方法有效，并且开发人员对此感到满意。