Skip to content
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

[RFC][python] deprecate advanced args of train() and cv() functions and sklearn wrapper #4574

Merged
merged 8 commits into from
Sep 12, 2021

Conversation

StrikerRUS
Copy link
Collaborator

@StrikerRUS StrikerRUS commented Aug 29, 2021

Proposing this PR to include in #4310

I also think this release could be a good opportunity for maintainers to think carefully about what breaking changes might be made (in addition to #3234) in a 4.0.0 release, and to add deprecation warnings for them in the 3.3.0 release.

Encourage users to use callbacks. With removed in 4.0.0 release advanced arguments codebase will become a little bit clearer, confusing cases when both callback and corresponding advanced argument are used will be eliminated, there will be no need to expose new callbacks or new arguments of existing callbacks (#2526) via new arguments of high-level functions/classes making signature of functions incredibly difficult to understand especially for newcomers.

@StrikerRUS StrikerRUS changed the title [WIP][python] deprecate advanced args of train() and cv() functions and sklearn wrapper [RFC][python] deprecate advanced args of train() and cv() functions and sklearn wrapper Aug 30, 2021
@StrikerRUS StrikerRUS marked this pull request as ready for review August 30, 2021 02:54
@StrikerRUS StrikerRUS requested a review from guolinke August 30, 2021 02:54
@jameslamb
Copy link
Collaborator

jameslamb commented Aug 31, 2021

I'm supportive of this idea, but could we preserve the current behavior where .best_iteration_ and .best_score_ are None if early stopping is not used?

Having those now be 0 is a breaking change and I think we should only make that breaking change in 4.0.0. There could be user code out there that is using _best_iteration_ is None as a way to detect whether not early stopping was used.

@@ -50,19 +50,27 @@ def _format_eval_result(value: list, show_stdv: bool = True) -> str:


def print_evaluation(period: int = 1, show_stdv: bool = True) -> Callable:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe we could rename this to log_evaluation as well? Seems like it is only used in engine right now so it could be a good time before it is used explicitly as a callback.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jmoralez

Good idea, I like it! Unfortunately, print_evaluation() callback is already in public API, so we cannot simply rename it.
https://lightgbm.readthedocs.io/en/latest/Python-API.html#callbacks

I'll prepare a separate PR for that if you don't mind.

@StrikerRUS
Copy link
Collaborator Author

@jameslamb

could we preserve the current behavior

Sure, will revert some lines of code.

@StrikerRUS
Copy link
Collaborator Author

@jameslamb

could we preserve the current behavior

Addressed in 07046ec.

or :obj:None

in best_score_'s docstring was just a mistake. It's always a dict, possibly an empty one.

Also, fixed a bug when best_iteration_ was not set if early stopping was specified via keyword arguments or a callback, which is now a recommended way of specifying early stop.
In addition, fixed a bug when best_iteration_ and evals_result_ were preserved (not updated) after a previous call to fit() method. This happens when the first call was with early_stopping_rounds=xx and the seconnd one without early_stopping_rounds=None.

I can extract bug fixes into separate PRs to make this one easier to review if needed.

Copy link
Collaborator

@jameslamb jameslamb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can extract bug fixes into separate PRs to make this one easier to review if needed.

I can see where the bug fixes are and understand them, think it's ok to leave them in this PR. Thanks very much for those!

This looks great to me, I have no other comments. Sorry it took a few days to come review this.

Really looking forward to the point in the future where we come back and remove all these deprecation warnings and backwards-compatibility things in the Python and R packages 😀

@StrikerRUS StrikerRUS merged commit 86bda6f into master Sep 12, 2021
@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants