Updating filters at runtime

[kiml]

Great package.

I'm asking about updating (primarily) filters at runtime.
I have a need to update at least filters (possibly level too).
The current view seems to be that runtime changes are not 'reasonable', and the API will not assist you.

My 2c is that the concept of updating logging configuration at runtime is a perfectly reasonable pattern and therefore it would be excellent for Loguru to support it in an elegant manner via at least ONE of the following:

• via an update() or extending the add() interface trivially to allow deltas, AND/OR
• provide a get configuration() method

If I had to pick just one, I'd suggest that get configuration() has more use cases/flexibility.
I am not aware of a get current configuration() function (I think implementing was discussed but not acted on). If it does exist in a more recent version then my apologies for not seeing it (and most of this issue is moot and can be closed).

For your interest (but I don't see that it changes the arguments) in my use-case I need to change the filters at runtime so I can vary the level of debugging in a complex running app that I do not want to kill and restart just to change the logging level to troubleshoot dynamic runtime problems. When I'm done, I can set the logging back to the default - all without killing the app, which apart from not being desirable in a production environment, killing and restarting also often removes the exact runtime state that needs the extra debugging. Leaving debugging always on maximum, just in case, is not a reasonable solution either.

-- Discussion --

I'm aware of the comments in issues:

• Getting the current configuration of the logger Getting the current configuration of the logger #239
• Support getting/updating handlers? Support getting/updating handlers? #251
• Change level of handler... Change level of handler... #335

I understand that the Logger can partially print its configuration via printing the logger variable.
I'm aware of the general concerns around API size creep and adding "random" functions. I'm all for small/neat/elegant APIs :-).

I'm aware that I can use "remove" and "add" to effectively change a handler and achieve what I want, however I feel this is slightly clunky for the following reasons:

• There is no get configuration() so I need to maintain a copy of the quite complex logging configuration that the Logger already knows! Keeping this info in two places in the running app is an (admittedly smallish in my case) nuisance. Sure I can do it but that feels like an anti-pattern to me. The GET-MODIFY-SET pattern has existed as a good pattern since cavemen started programming IBM mainframes ;-)
• remove/add may also potentially result in a transient loss of logging information. I don't know if there are other negative impacts as I haven't thoroughly studied it. I can live with this approach, but it fails my elegance test.

One argument I've read for not implementing configuration() is that the logger should be configured in one place.
I do only configure my logger in one place and I think it an excellent recommendation, It is however a borderline overly categorical statement. In my case however it's not so much the "place" as the "time". I need to configure it multiple times and I'd rather not have to cache the original config or reparse files just to make a change - this introduces extra state unnecessarily. There's also the risk of the cached values not being consistent with the actual logging values (although a discrepancy risks being the result of a poor design). So we come back to GET-MODIFY-SET.

Look forward to feedback.

cheers
Kim