Open fkiraly opened 2 years ago
@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 BaseObject
to pass scikit-learn's check_is_estimator
.
To do this we need to look into sklearn's check_is_estimator
to see the scope and format of sklearn's checks. If their checks are duck typed, a nice outcome is that estimators that inherit from BaseObject
are able to pass sklearn's check_is_estimator
directly. If the checks in sklearn's check_is_estimator
are instead checking for direct inheritance from the sklearn BaseEstimator
(in addition to checking the interface) we may need have tests that validate that you can construct an estimator object that inherits from sklearn's BaseEstimator and baseobject's BaseObject
to get the BaseObject
interface and pass sklearn's check_is_estimator
.
An alternative would be to check the main interoperation points: get_params
and set_params
.
That would require building composites either way round and see whether the nested access and write still works.
From https://github.com/sktime/BaseObject/issues/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.