For me, I prefer the final API to raise an error. In your example, LogisticRegression is configured to have a sample_weight, but is it not provided one. If we do nothing, then the following two pipelines have the same behavior:

pipeline = make_pipeline(LogisticRegression().set_fit_request(sample_weight=True)).fit(X, y)

pipeline = make_pipeline(LogisticRegression()).fit(X, y)

That feels weird to me.

Do you think the final API should be strict by default?

I don't mind having it strict by default, but I might be missing some edge cases. Would you have something in mind to object the default strict mode @jnothman ?

Basically by not being strict we're allowing for someone to provide us with a canned composite estimator with sample_weight supported but not required. If an estimator truly requires sample_weight it will raise in any case; but as long as we're not being strict allow for default behaviours in reusable composite estimators.

By saying set_fit_request(sample_weight=True) I don't think the user is asking you to validate their input differently, but rather that if sample_weight is provided it should go to the requested place. I acknowledge that these semantics are somewhat confusing, but I'm not sure how to fix them.

Some options out there:

• Rename RequestType.REQUESTED to RequestType.EXPECTED and add RequestType.ACCEPTED. The current True value can be the proxy for either of them.
• Introduce a "strict" mode, the default can be either True or False
• rename set_fit_request to set_fit_metadata_acceptance (or similar)
• Do nothing for now

I'm personally happy with either of the above solutions.

set_fit_receives? I don't see a lot of risk (albeit some user confusion) from these staying as optional.

For me, I prefer the final API to raise an error. In your example, LogisticRegression is configured to have a sample_weight, but is it not provided one. If we do nothing, then the following two pipelines have the same behavior:

pipeline = make_pipeline(LogisticRegression().set_fit_request(sample_weight=True)).fit(X, y)

pipeline = make_pipeline(LogisticRegression()).fit(X, y)

That feels weird to me.

Do you think the final API should be strict by default?

I agree with this example being weird, and to make the example even more poignant, the below two are identical.

pipeline = make_pipeline(LogisticRegression().set_fit_request(sample_weight=True)).fit(X, y)

pipeline = make_pipeline(LogisticRegression().set_fit_request(sample_weight=False)).fit(X, y)

I personally would prefer some explicit parameter that will raise. To illustrate an example, suppose someone investigating the hypothesis of: "does sample_weight help my estimator?"

Research code is often hasty and you might expect that setting sample_weight=True means that it will use the sample_weight and sample_weight=False does not. Then in the process of writing the evaluation code, a mistake was made and the sample_weight was never passed in.
At the end I look at my numbers and conclude it does not help my estimator.

Of course this is an example of user error, but sklearn is very good at validating correctness and the expectations for this new feature would be no different. From experience, experimentation code in machine learning research is riddled with these subtle bugs and sklearn is great at informing users about them.

As for the exact semantics of specifying "strict" or True or some enum value, I don't think it matters too much.

One API recommendation to limit new methods or new parameters to simply introduce a new value type that determines behaviour, namely .set_fit_request(sample_weight="strict") or .set_fit_request(sample_weight="required"). I don't think this would conflict with anything but there might be code that already exists that does something like:

if param["sample_weight"]:  # Relies on implicit "truthyness"
   # do...

The above proposal would not work in this case as bool("strict") == True.
This can be fixed internally in sklearn but depending on the current adoption of metarouting, this could introduce a silent bug in existing code.

EDIT: The above API with "strict" proposal would technically conflict with semantics defined in 1.1.4. Advanced: Different scoring and fitting weights. It would be odd for someone to use it but it means that simply checking for a str would not work internally. I don't have any other ideas that weren't mentioned in that case.