Skip to content

Conversation

@adrinjalali
Copy link
Member

Fixes #22987

This PR makes fit_predict and fit_transform composite methods whose requests are a combination of the corresponding simple methods.

This makes it easier for the user to only care about setting requests for fit and transform.

This PR is implemented as forcing the user to have the same requests for the two methods if the metadata name is the same, otherwise it raises an error. Making it more flexible would require fit_transform and fit_predict to do routing, which I think we'd like to avoid.

cc @jnothman @thomasjpfan @jnothman @glemaitre

@adrinjalali
Copy link
Member Author

Codecov fail can be ignored.

@glemaitre
Copy link
Member

On the principle, I am fine.

I am thinking about LocalOutlierFactor. If I am not wrong, depending on the novelty parameter, fit_predict can be called or not. Do you foresee any issue with such an estimator where fit_predict but not fit_predict or something around this case?

@adrinjalali
Copy link
Member Author

The parameters passed to the underlying methods don't depend on whether fit_predict is called or fit and predict. So I don't see any issue there.

But that reminds me that we should fix all our composite method to accept kwargs and pass them to the underlying methods. I'll work on that fix.

@jnothman
Copy link
Member

I agree that this seems like a good thing to do......

Copy link
Member

@glemaitre glemaitre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. There is only the pattern discussed by @thomasjpfan that might be worth looking at.

@adrinjalali adrinjalali requested a review from thomasjpfan March 14, 2023 11:15
Copy link
Member

@thomasjpfan thomasjpfan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm guessing this can wait for #24027 to be merged first?

MethodMetadataRequest(router=self, owner=owner, method=method),
)

def __getattr__(self, name):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can there be a docstring to explain what this method is doing? At a glance, it looks like it is dynamically creating the metadata routing for the composite methods.

Also, what do you think of setting COMPOSITE_METHODS during MetadataRequest.__init__? It would increase the size of the object, but we do not need override __getattr__.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@thomasjpfan that would require setting them as descriptors (which we can do), and to make it dynamic based on the values in COMPOSITE_METHODS it'd need a meta class with __init_sublcass__ or an ABC meta-class. Can surely do, but I'm not sure if it's more understandable/easier than this approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants