check_estimator set all of the parameters from get_params to different test values and changing the logical value of compat also changes what get_params returns.
There is no straightforward solution to this problem because check_estimator disallows parameters that change other parameters of the same estimator in any way.
In general, there are three possibilities how wrappers could present the parameters of the wrapped estimator:
As a nested estimator in the same way as e.g. pipelines. The parameters would then be referred to as estimator_param1, etc. Kind of ugly when you want to set e.g. parameters when grid-searching a pipeline.
The way it is currently with compat=True, i.e. the estimator being a single parameter. Again very ugly when you want to change the parameters of a wrapped estimator afterwards, especially for grid search.
Storing estimator and parameters seperately on construction and when calling set_params. (The estimator as its type and the parameters as class attributes. Possibly the most elegant solution, the only problem could occur when estimators define parameters with the same name as the wrapper.
In any case, if all of these possibilities were to be implemented, we would have to define a dedicated wrapper class for each and have wrap return the appropriate class according to the compat argument.
check_estimatorset all of the parameters fromget_paramsto different test values and changing the logical value ofcompatalso changes whatget_paramsreturns.There is no straightforward solution to this problem because
check_estimatordisallows parameters that change other parameters of the same estimator in any way.In general, there are three possibilities how wrappers could present the parameters of the wrapped estimator:
estimator_param1, etc. Kind of ugly when you want to set e.g. parameters when grid-searching a pipeline.compat=True, i.e. the estimator being a single parameter. Again very ugly when you want to change the parameters of a wrapped estimator afterwards, especially for grid search.set_params. (The estimator as itstypeand the parameters as class attributes. Possibly the most elegant solution, the only problem could occur when estimators define parameters with the same name as the wrapper.In any case, if all of these possibilities were to be implemented, we would have to define a dedicated wrapper class for each and have
wrapreturn the appropriate class according to thecompatargument.