Users can now pass in all valid kwargs to Estimators #1157
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1157 +/- ##
=======================================
Coverage 99.91% 99.91%
=======================================
Files 197 197
Lines 11663 11705 +42
=======================================
+ Hits 11653 11695 +42
Misses 10 10
Continue to review full report at Codecov.
|
freddyaboulton
force-pushed
the
1155-cant-pass-in-certain-kwargs
branch
from
2f1e873
to
3b01f7a
Compare
freddyaboulton
requested review from
angela97lin,
dsherry,
eccabay,
jeremyliweishih,
bchen1116 and
christopherbunn
| estimator = estimator_class() | ||
| if estimator._component_obj is None: | ||
| pytest.skip(f"Skipping {estimator_class} because does not have component object.") | ||
| params = estimator._component_obj.get_params() |
There was a problem hiding this comment.
Does this test if all estimators accept the default keyword arguments and values of the component_obj?
freddyaboulton
force-pushed
the
1155-cant-pass-in-certain-kwargs
branch
from
3b01f7a
to
dcef397
Compare
…r, ENClassifier, and Catboost estimators.
freddyaboulton
force-pushed
the
1155-cant-pass-in-certain-kwargs
branch
from
dcef397
to
62d3b30
Compare
| 'silent': silent} | ||
| if kwargs.get('allow_writing_files', False): | ||
| warnings.warn("Parameter allow_writing_files is being set to False in CatBoostRegressor") | ||
| kwargs["allow_writing_files"] = False |
There was a problem hiding this comment.
@freddyaboulton it looks like this code updates allow_writing_files so that it will always be False. Why is this necessary? If a user wants to set this parameter, why not allow them? We can still encode a default like so, without adding this parameter to the parameters dict:
cb_parameters['allow_writing_files'] = kwargs.get('allow_writing_files', False)There was a problem hiding this comment.
This question also applies to the changes for catboost classifier and elasticnet classifier as well.
There was a problem hiding this comment.
Discussed with @freddyaboulton .
Options:
- Allow users to set allow_writing_files to whatever they want. Make it a named field.
- Add the ability to have an allow-list and deny-list for parameters. I.e. if someone passes in allow_writing_files, we raise an error.
- Keep code as-is
We liked the first option. Let's expose allow_writing_files as named value in init, default False, and delete the warning code here
| @@ -26,8 +26,6 @@ def __init__(self, penalty="l2", C=1.0, n_jobs=-1, random_state=0, **kwargs): | |||
| parameters.update(kwargs) | |||
|
|
|||
| lr_classifier = LogisticRegression(random_state=random_state, | |||
| multi_class="auto", | |||
| solver="lbfgs", | |||
There was a problem hiding this comment.
@freddyaboulton is there a reason why we shouldn't add these as named parameters to init, so that the defaults are still clear?
def __init__(self, ..., multi_class='auto', solver='lbfgs', ..., **kwargs):There was a problem hiding this comment.
Discussed with @freddyaboulton .Plan: let's do this.
Pull Request Description
Fixes #1155
After creating the pull request: in order to pass the release_notes_updated check you will need to update the "Future Release" section of
docs/source/release_notes.rstto include this pull request by adding :pr:123.