-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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 silent
and standalone verbose
args. Prefer global verbose
param
#4577
Conversation
if verbose: | ||
_log_info(f'Finished loading model, total used {int(out_num_iterations.value)} iterations') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this one, I don't think one log line deserves a standalone argument. Users are able to get number of iterations after constructing a Booster if needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree! (sorry I missed commenting on this in my previous review)
fd4dd10
to
976b5c5
Compare
976b5c5
to
fdc8d84
Compare
I support this change, good idea! But I have a mild preference for these deprecation warnings to use language like "in a future release of lightgbm" instead of "in the 4.0.0 release". This way if something happens and we end up not making all of these changes in exactly 4.0.0 (i.e. in case we make mistakes), that warning would still be accurate. Since LightGBM doesn't do long-term support release (i.e. there wouldn't be a 3.3.1 release after 4.0.0 is out), I don't think it's necessary to list a specific future version in deprecation warnings. |
I think it's better to be explicit and specify exact version we're targeting. I understand your worries, but these changes are quite easy to implement and I hope nothing can prevent us to include them in |
silent
and standalone verbose
args. Prefer global verbose
paramsilent
and standalone verbose
args. Prefer global verbose
param
It wouldn't be misleading in that example, because in that situation I expect that these deprecations warnings would still be left in the library in a 3.3.1 release. So both 3.3.0 code and 3.3.1 code would say "in a future release of lightgbm" if you are using the deprecated behavior. I think that "a future release" is general enough that it won't / shouldn't be interpreted to mean "the next release". As a general rule, I just think that log messages in libraries shouldn't be used as a source of information about very specific future versions, since we can't say with certainty right now whether the release that these deprecations will be removed in will be 4.0.0 or 4.0.1 or 4.1.0 or 5.0.0. We have a specific plan and it seems that the most likely situation is that these deprecations will become errors in exactly 4.0.0, but I don't think that's guaranteed to be true. |
Ah, here is where we are thinking differently. For me personally "a future release" === "the next release".
This statement is quite controversial, I think. For instance, scikit-learn has very strict and formal rules of a deprecation process and always specify target version for a removal.
So, I believe it depends on development policy whether warnings should be explicit or not. However, I don't have a strong preference and will rephrase all warnings. |
Totally hear your concerns, and I think the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks great, thanks for doing this before 4.0.0!
silent
and standalone verbose
args. Prefer global verbose
paramsilent
and standalone verbose
args. Prefer global verbose
param
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. |
Proposing this PR to include in #4310
Having multiple params and arguments that control verbosity is quite confusing, see #1157 (comment). I believe leaving only
verbose
keyword argument, that is described in our general parameters guide and which one that a lot of users is used to simply set to-1
, will simplify user experience and decrease the maintainance burden for us.