-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
compatibility with sklearn BaseEstimator
#12
Comments
@fkiraly this is a good thought. But I want to make sure I know the context your thinking of.Are you thinking in terms of an eventual check interface (e.g. check_is_object) or something else? I'm in favor of duck typing that check but including a param to require a "strict" check (is also a sub class of BaseObject). We might consider grouping the checks used in something like check_is_object by interface and having a parameter that controls what to check for (e.g. just get_params/set_params, tags, testing, etc). That would provide the most downstream comparability (sklearn baseobject for instance could pass) and provide users the means to test for just the interface required in their use case. In terms of the interface implementation: I believe the get_params/set_params interface uses duck typing, so it should work with like objects. One option is to ensure that remains and make sure the other interfaces (testing and tags) do the same. |
Based on our call we also want to have tests that test the ability of estimators inheriting from To do this we need to look into sklearn's |
An alternative would be to check the main interoperation points: That would require building composites either way round and see whether the nested access and write still works. |
From #17, another interoperation point is pretty printing. |
We should have a list of interoperation points we need to test, actually. |
Question: how do we ensure compatibility with sklearn
BaseEstimator
and similar classes?This might not be out of the box, if we check inheritance from
BaseObject
as opposed to availability of certain methods.We could register a list of similar classes, but it would be better if this is out of the box compatible, e.g.,
get_params
nesting and so on.The text was updated successfully, but these errors were encountered: