[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.
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.
agree! (sorry I missed commenting on this in my previous review)
StrikerRUS
force-pushed
the
deprecate_silent
branch
from
fd4dd10
to
976b5c5
Compare
StrikerRUS
force-pushed
the
deprecate_silent
branch
from
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 |
StrikerRUS
changed the title
silent and standalone verbose args. Prefer global verbose paramsilent and standalone verbose args. Prefer global verbose param
StrikerRUS
requested review from
chivee,
henry0312,
jameslamb,
jmoralez and
shiyu1994
as code owners
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 |
jameslamb
changed the title
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
verbosekeyword 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.