This is one of the cases where the current system just works, and the proposal seems highly bureaucratised :(

I started writing this:

Another alternative that I have explored for meta-estimators such as this one, which "only" pass metadata to the single sub-estimator they have, is to behave like a consumer rather than a router, and expose their sub-estimator's requests.

And realized there could potentially an issue with this implementation since MultiOutputClassifier implements its own score, which would make it a consumer and a router. In this case it's not an issue since the score method doesn't accept any metadata.

I do wonder if we should just be using fit params without distinguishing from partial_fit. Did we have use cases for distinguishing fit and partial_fit params?

If we do that, do we want to also consider predict_proba, predict_log_proba, decision_function, and predict all having the same request and we could have common tests making sure they all accept the same metadata in their signature. Should we do that?

This is one of the cases where the current system just works, and the proposal seems highly bureaucratised :(

I'm not sure what to do with this concern @jnothman 😆

But I also don't think it's too bad. If this estimator would accept sample_weight for its score (which it does override, but somehow doesn't take sample_weight into account), then it would be a router AND a consumer, and the SLEP works perfectly fine.

I do wonder if we should just be using fit params without distinguishing from partial_fit. Did we have use cases for distinguishing fit and partial_fit params?

Seems like we're keeping them separate then? (#22988)

The summary of the latest change:

Previously the code would try to route parameters, and if there was an exception, it would try to assume all those parameters as requested, and then route again.

Now, the exception includes enough information that when raised, we can check if those relevant parameters can be routed and warned or if there should be an error.

It also made me change the signature of warn_on method to include which metadata for each method should raise a warning. This means for instance, if previously fit was routing sample_weight but not other metadata, we would warn on sample_weight having not request value, but raise an error on others, since the routing of other metadata is newly implemented.

Opened #23928 to discuss the verbosity issue.

The lines reported not covered are the dummy estimators. I think this is fine if they are not tested.

Thanks @adrinjalali