@DaMuBo According to the official documentation, I think your MyEstimator should inherit from BaseEstimator as well.

import numpy as np
from sklearn.base import BaseEstimator, ClassifierMixin

class MyEstimator(ClassifierMixin, BaseEstimator):
    def __init__(self, *, param=1):
        self.param = param

    def fit(self, X, y=None):
        self.is_fitted_ = True
        return self

    def predict(self, X):
        return np.full(shape=X.shape[0], fill_value=self.param)

The code snippet above runs fine with your .fit() and .predict() calls. sklearn also provides sklearn.utils.estimator_checks.check_estimator which you can validate your custom estimator as well. I myself find it very useful for production-grade implementation.

@gunsodo
Yes we are not exactly following the documentation here.
We will change that on our side in the future for more robust code.

Thanks for the hint to the check_estimator we'll look into it.

But i also think the ClassifierMixIn shouldn't use a method which it can't execute.

I would still consider this breakage as a regression. We made effort to raise a proper deprecation warning such that user that defined compatible estimators have one version to change their code.

While we strongly advocate for using BaseEstimator and would request it in 1.7, I think that the Mixin should indeed not break but instead raise the same deprecation warnings than when one inherit from BaseEstimator.

We should probably have a try/except around the super call and if failing, get the default_tags and populate it.

@adrinjalali do you think that it is a reasonable way forward?

I'd rather make ClassifierMixin inherit from BaseEstimator instead (it's not a mixin per say then anymore though).

We certainly shouldn't "fix" the issue as proposed in #30480 since it breaks code if inheritance order is wrong.

The code written here in the OP is simply "not supported", however, it's the kinda thing that was supported before, albeit dysfunctional and wrong.

I'd suggest two things:

• improve the inheritance order check test, to make sure if there's any of the mixins present, BaseEstimator is also present, and call the test before trying to get tags
• The issue here is coming from get_tags called in check_is_fitted, which was a fix in this release too. We can make get_tags catch that particular exception, raise a deprecation warning, and return default tags, and the warning says that the code "runs", but it's probably wrong.

I still have this issue with TransformerMixin in 1.6.1. What is the intended fix?

My code is something like

class TransformCoerce(TransformerMixin, BaseEstimator):
    """Coerce input data to all numeric for xgboost."""
    def fit(self, X, y):
        return self 
    
    def transform(self, X):
        cols = X.columns.tolist()
        value_cols = list(filter(lambda x: x.endswith("value"), cols))
        X[value_cols] = X[value_cols].apply(lambda x: pd.to_numeric(x, errors="coerce"))
        return X 

pipeline = Pipeline([("transformer", TransformCoerce()),
                     ("xgb", xgb.XGBClassifier(enable_categorical=True))])

X, y = df.drop("GT", axis=1), df["GT"]

clf = pipeline.fit(X, y)

# in-sample predictions for simplicity
y_pred_prob = clf.predict_proba(X)
print(y_pred_prob)

All the online tutorials say to inherit from TransformerMixin and BaseEstimator. In particular https://scikit-learn.org/stable/modules/generated/sklearn.base.TransformerMixin.html

Is it an issue to do with xgboost?

@jxu this is not a reproducer, so I can't really answer. But xgboost doesn't have any issues if you use latest xgboost and scikit-learn versions.

@jxu this is not a reproducer, so I can't really answer. But xgboost doesn't have any issues if you use latest xgboost and scikit-learn versions.

Yes, it is all fixed with latest versions. From https://stackoverflow.com/questions/79290968/super-object-has-no-attribute-sklearn-tags either I had to downgrade to sklearn 1.5.2 or upgrade xgboost to 3.0.