[R-package] add deprecation warnings on uses of '...' in predict() and reset_parameter()

[jameslamb]

Contributes to #4310 (based on #4226 (comment)).

This PR proposes adding some deprecation warnings on uses of ... for parameters in the following functions:

• predict.lgb.Booster()
• Booster$predict()
• Booster$reset_parameter()

Notes for reviewers

Removing ... from reset_parameter() in release 4.0.0 would make that method's signature identical to the Python package's implementation.

LightGBM/python-package/lightgbm/basic.py

Line 2870 in 4db10d8

def reset_parameter(self, params):

However, removing ... from the signature of Booster$predict() and predict.lgb.Booster() would be different from the behavior in the Python package, which allows additional parameters passed through **kwargs.

LightGBM/python-package/lightgbm/basic.py

Lines 3399 to 3401 in c65a2e3

	def predict(self, data, start_iteration=0, num_iteration=None,
	raw_score=False, pred_leaf=False, pred_contrib=False,
	data_has_header=False, is_reshape=True, **kwargs):

I think not allowing ..., and instead encouraging the use of params, for additional prediction parameters is a better interface for the R package. It makes that interface consistent with all the other parts of the R package which use params (like Dataset construction and training), and leaves open the possibility of an improved user experience with "other" prediction parameters by implementing something like a prediction-parameters-specific version of the feature described in #4195 (comment).

But @StrikerRUS , if you feel strongly that consistency with the Python package is more important than enabling that eventual "generate a params list from a function" feature for the specific case of predict() methods, I'd be ok with leaving the ... for them.

[jameslamb]

I'll look into these CI failures on Mac and Linux most R builds tomorrow:

predict.lgb.Booster: no visible global function definition for
  ‘modifyList’
Undefined global functions or variables:
  modifyList
Consider adding
  importFrom("utils", "modifyList")
to your NAMESPACE file.

ref: https://github.com/microsoft/LightGBM/runs/3396977164?check_suite_focus=true

Maybe modifyList() now needs to be explicitly imported and used with ::. Very weird, given that it's used in several other places on master without causing any issues.

[jameslamb]

I just pushed 799bd01 to address #4548 (comment)

I'm still not sure why this NOTE is only showing up now, but that commit should fix it.

[StrikerRUS]

TBH, I'm not sure what consistency is better: consistency with the Python-package or consistency across the R-package. Probably the latter, but will defer to other maintainers' opinion.

[StrikerRUS]

I suppose we should update all our tests (and examples, but if I'm not mistaken, we don't have any yet) and use params in them to silence new warning.

[jameslamb]

Have you seen any such warnings or places where prediction parameters are passed through in our examples or tests? I checked through the tests and didn't find any uses of extra parameters that didn't match the other keyword arguments already.

To be clear, this would only apply for passing the parameters listed at https://lightgbm.readthedocs.io/en/latest/Parameters.html#predict-parameters, such as pred_early_stop.

I searched for those parameters with git grep and didn't find any uses in the R package. For example, with

git grep pred_early_stop R-package/

[StrikerRUS]

Sorry, didn't know that you had already done it! Then everything is OK with this PR I think. But it's a good sign to add a test for those parameters in R-package 😉

[jameslamb]

No problem, I should have mentioned it. And definitely agree that it's a sign of a missing test.

[jameslamb]

TBH, I'm not sure what consistency is better: consistency with the Python-package or consistency across the R-package. Probably the latter, but will defer to other maintainers' opinion.

Ok thank you! I think consistency within the R package is probably more important, and consistency between R and Python is valuable but not AS important.

So I think we should move forward with introducing this params pattern for extra prediction parameters in the R package.

[StrikerRUS]

LGTM, thanks!

[github-actions]

This pull request has been automatically locked since there has not been any recent activity since it was closed. To start a new related discussion, open a new issue at https://github.com/microsoft/LightGBM/issues including a reference to this.